bobm%pixel@uunet.UU.NET (01/07/91)
The pc532 software "distribution" is spread out all over the place.
I'd like to acquire sources for everything I've got, and a few things
I don't have yet, but I'm not sure where everything is.
Minix kernel:
Floppy from bruce.
Update dated 9/1/90 posted to pc532-src.
memory allocation patch dated 11/12/90
Is that all?
Minix utilities:
Some on floppy from bruce.
More on Prentice-Hall floppy?
Where are the rest? How about kermit, compress, uuencode,
libc:
On Prentice-Hall floppy?
gcc, as, ld:
Where can I get this? What's the "current" version?
gnu emacs:
Has anyone gotten this to work yet?
g++:
Has anyone made this work yet? On a pc532 or on any ns32k machine?
gnu utilities:
Which ones work on minix? tar? grep? File utilities?
How about bash?
uucp:
posted to pc532-src.
ksh:
posted to pc532-src.
Thanks for info.
K<bob>kls@ditka.Chicago.COM (Karl Swartz) (01/07/91)
> The pc532 software "distribution" is spread out all over the place. > I'd like to acquire sources for everything I've got, and a few things > I don't have yet, but I'm not sure where everything is. This is certainly a problem if you don't want to replay the same scavenger hunt that everybody else has gone on. I had hoped that Minix for the pc532 could be done as nicely and professionally as the hardware but the reaction I seemed to get from everybody other than Dave and George was "that's the fun of Minix" and "this a'int a Mac." :-( Lacking a great deal of tinkering time, my pc532 has largely ended up being a space heater. As expressed before, I'd be willing to help rectify this if there is any interest out there. > On Prentice-Hall floppy? This is a poor solution for those of us with no way to read them. (Perhaps I shouldn't assume that one can use pc532 Minix without a piece of Intel garbage.) > Minix kernel: > Floppy from bruce. > Update dated 9/1/90 posted to pc532-src. > memory allocation patch dated 11/12/90 > Is that all? There's also the clock chip (/dev/rtc) patch. > gnu emacs: > Has anyone gotten this to work yet? I have a nearly functional version of jove 4.13. If there's any interest I'll spend some time going to 4.14 and packaging it up. > uucp: > posted to pc532-src. This was only a partial implementation. I've fixed a few more bugs since then, though it still doesn't know how to make outgoing calls. A few things are hacked pending kernel support. I've also ported smail 2.5. Only a couple of minor changes; I'm not sure if I posted about this or not. > ksh: > posted to pc532-src. >From what I could figure you first need to port ESTDIO to get this running. Seems to me I grabbed it but ran out of time to spend on porting that too. -- Karl Swartz |INet kls@ditka.chicago.com 1-408/223-1308 |UUCP {uunet,decwrl}!daver!ditka!kls |Snail 1738 Deer Creek Ct., San Jose CA 95148 "It's psychosomatic. You need a lobotomy. I'll get a saw."
phil%strawberry.cs.wwu.edu@RELAY.CS.NET (Phil Nelson) (01/07/91)
>The pc532 software "distribution" is spread out all over the place. >I'd like to acquire sources for everything I've got, and a few things >I don't have yet, but I'm not sure where everything is. I know how you feel. That is why I started a collection of these things. Many sources are in the PH minix disks. If you have the minix 1.5 distribution, you will find kermit, zmodem and many more sources. GNU sources are available on prap.ai.mit.edu (as expected.) I have made a collection of some sources on willow.cs.wwu.edu. The files are in pub/minix532. I plan to continue to collect the minix sources here. Currently there are only a few sources. It includes clam1.3, ue (source to the emacs editor distributed with minix532), mg2 (another microemacs editor, I think it is better than ue.), and for Earl Chew's ls (This is the ls distributed with minix532). I don't know if now is the time, but I will go ahead and "spill the beans." Bruce C. and I are working on a minix 1.5 version that uses most of the 1.3 kernel but all of the 1.5 fs and mm. It allows 64 meg partitions and has a lot more commands. I currently am running a version that uses the 1.5 TTY driver. It is much better than the 1.3 TTY driver. We are now down to the "last few bugs" to get out of the system before we distribuite it. So you can make use of it when it comes, you will need the following things: a) a minix 532 distribution from Bruce. b) a complete copy of minix 1.5 (for the pc) Make sure you have the crc's as AST posted them last April (I think it was April). c) Some extra disk space.... Please don't ask when this will be available until after Feb 15. Instead, use your effort to get a complete 1.5 source tree. The distribution will be a set of diffs off a combination of the original minix532 distribution and the 1.5 sources. After the distribution of the 1.5 hybrid, I will update the archive on willow.cs.wwu.edu to include the 1.5 distribution and sources to other things I have on my 1.5 system. It includes mg2, flex2.3, berkeley yacc and several other things. I hope to get uucp and other things in the "archive". --Phil
sverre@lars.Seri.GOV (Sverre Froyen) (01/07/91)
> >As expressed before, I'd be willing to help rectify this if there >is any interest out there. Yes, YES, YES!!! (there is interest). >> On Prentice-Hall floppy? > >This is a poor solution for those of us with no way to read them. >(Perhaps I shouldn't assume that one can use pc532 Minix without a >piece of Intel garbage.) I would suggest FTP first and DOS floppies second. Minix floppies only work if (i) you have a floppy drive on your 532 (which I suspect most of us do not have) or (ii) you have a PC running Minix (a PC running DOS is much easier to borrow). I would also prefer to see patches against some well defined original (e.g. GNU sources) rather than the whole thing. (I realize, of course, that in many cases there is no well defined original.) In addition a working binary might be useful, see below. > >I've also ported smail 2.5. Only a couple of minor changes; I'm >not sure if I posted about this or not. No, this was not posted. > >> ksh: >> posted to pc532-src. > >>From what I could figure you first need to port ESTDIO to get this >running. Seems to me I grabbed it but ran out of time to spend on >porting that too. I started on this too and immediately ran into problems. The Minix shell would choke on the configuration scripts, and Minix make could not handle the make files. I decided to start from the bottom with gcc 1.38, bash, gnu make, file utils, etc. I have a working gcc 1.38 and an almost working bash (thanks to Bruce and the guys in Finland). (I'll be happy to post my changes, however, since I know very little about compilers and I just sent off my changes to Bruce I think it would be better to wait for his stamp of approval before making this version official). Enough rambling. What I really set out to say was that there seems to be a bootstrap problem. A number of the gnu (and other) utilities are difficult or impossible to port without some other utility running. Therefore, it would be useful also to have working binaries available, e.g., for FTP. Furthermore, when you are posting patches, a short description of your system (e.g. what other utilities are needed) would be very useful. Sverre -- Sverre Froyen sverre@seri.gov, sunpeaks!seri!sverre
phil%strawberry.cs.wwu.edu@RELAY.CS.NET (Phil Nelson) (01/08/91)
>GNU sources are available on prap.ai.mit.edu (as expected.)
Sorry for the error (bad typing...) it should be
prep.ai.mit.edu
--Philbdale@col.hp.com (Bdale Garbee) (01/08/91)
> Enough rambling. What I really set out to say was that there seems > to be a bootstrap problem. Yes, very true. > Therefore, it would be useful also to have working binaries available, > e.g., for FTP. Furthermore, when you are posting patches, a short > description of your system (e.g. what other utilities are needed) would > be very useful. Agreed. I'd go one step further. I hate having to patch and patch something that someone else has already merged the patches to and goten running. I'd like to see an FTP site with binaries of things folks have made work, *and* a snapshot of the sources as compiled. It's easy enough if you really care to grab the base version a person worked from, and diff the files yourself to patch a later base... or for the diffs to be provided too, but I would imagine many of us don't really care about the latest rev a lot of the time, we just want to make things work without spending all of our potential development time duplicating the efforts of others. I'd rather be building neat new interface hardware than applying patches to gcc, et al... 'nuff said. If it's an issue, I can make near-infinite FTP space available on col.hp.com, though it appears that there are other places with admins who might take a more active interest in maintaining such an archive. Bdale
jkp@cs.HUT.FI (Jyrki Kuoppala) (01/09/91)
In article <9101061431.AA12357@ditka.Chicago.COM>, kls@ditka (Karl Swartz) writes: >> gnu emacs: >> Has anyone gotten this to work yet? I have it compiling and almost working - it works fine otherwise but dumps core any time it tries to read from the minibuffer. I suspect a compiler problem - have to try it with the real 1.38, I'm still using a pre-release. >>From what I could figure you first need to port ESTDIO to get this >running. Seems to me I grabbed it but ran out of time to spend on >porting that too. I also have estdio installed, but the floating point doesn't work. These and other diffs are available from nic.funet.fi, directory pub/misc/pc-532/GNU-hut. They are still quite kludgy ports; I don't think it's worth the trouble to polish diffs for an outdated version of Minix. //Jyrki
news@daver.bungi.com (01/11/91)
> > Bruce C. and I are working on a minix 1.5 version that uses > > most of the 1.3 kernel but all of the 1.5 fs and mm. It allows 64 > > meg partitions [ K<bob> writes ] > I appreciate what you're doing, and I'll undoubtedly buy a copy, but > isn't a 64Mb partition kind of silly? Most pc532's already have one > or more 300 Mb disks, in a couple of years 1Gb drives will be common > on home machines. > > Wouldn't it be easier to change all the shorts to longs now? As part of the evolution to full POSIX compatibility, minix 1.6.x (which is currently being beta tested within the PC-Minix group) removes the 64Mb partition limit. Therefore, it seems to me the cleanest way to proceed at this point is to track the PC-Minix upgrades (ie. 1.3 -> 1.5.10 -> 1.6.xx). Though not released to the 1.6.x beta group, indications are that AST has decided to support sockets. My understanding is that it is currently in pre-beta testing. -- John Connin: manatee Orlando, Florida UUCP: {uunet,ge-dab,ucf-cs}!tarpit!tous!manatee!johnc
culberts@hplwbc.hpl.hp.com (Bruce Culbertson) (01/12/91)
bobm@pixel.convex.com writes: > > Bruce C. and I are working on a minix 1.5 version that uses > > most of the 1.3 kernel but all of the 1.5 fs and mm. It allows 64 > > meg partitions > > I appreciate what you're doing, and I'll undoubtedly buy a copy, but > isn't a 64Mb partition kind of silly? Most pc532's already have one > or more 300 Mb disks, in a couple of years 1Gb drives will be common > on home machines. Silly? Well, yes and no. Andrew Tanenbaum had very specific objectives for Minix, among them that Minix would run on computers which were cheap and plentiful. The minimal system he had in mind was an IBM-PC with floppies and without hard disks. To make a file system on a 360K floppy useful, the number of disk blocks devoted to file system management had to be kept to a minimum. It follows that the i-nodes have to be small. Since a large part of an i-node is an array of block numbers, the block numbers had to be small. Tanenbaum chose 16-bit block numbers. Since he also chose 1024-byte blocks, this resulted in a maximum file system size of 64 megabytes. None of this was silly, I think. Now, we come along with our 300 megabyte disks and use Minix. I guess that's pretty silly. A new file system has been (is being?) defined which will have 4-byte block numbers and i-nodes which are twice as large. This will appear in Minix 2.0, if not before. The i-nodes will also contain three dates instead of the current one date. It will be possible to mount both the new and old flavors of file systems at the same time. Phil Nelson was trying to make the point that Minix 1.5 fixes some bugs which made the actual maximum partition size of Minix 1.3 32 megabytes. 64 megabyte file systems are less silly than 32 megabyte file systems. > Wouldn't it be easier to change all the shorts to longs now? There is more to it than changing shorts to longs. The i-nodes are packed quite efficiently into a disk block and i-nodes never span a disk block boundary. Also, there is the issue of compatibility. While I bootstrapped the 32000 Minix port, it was extremely helpful to be able to mount the same file system on either a working IBM-PC Minix system or the new 32000 Minix system. Furthermore, all the PC-Minix utilities which know about the structure of a file system can be used on pc532-Minix without change. > BTW, I note that Bruce's gcc 1.35 recognizes "long long" (the 64 > bit integer) but that libc is missing some routines to support it. > Did you, Bruce, have to do anything to support long longs, or did > it just fall out of gcc for free? It just fell out for free. Is anyone interested in writing the support routines? I have not had occasion to use long-long's yet. Bruce Culbertson
bobm@pixel.convex.com (01/15/91)
I said: > > Wouldn't it be easier to change all the shorts to longs now? Bruce replied: > There is more to it than changing shorts to longs. The i-nodes are > packed quite efficiently into a disk block and i-nodes never span a disk > block boundary. Also, there is the issue of compatibility. I didn't realize the 1.5 filesystem would be 1.3 compatible. As Gilda Radner used to say, "Nevermind." K<bob>