jkh@meepmeep.pcs.com (Jordan K. Hubbard) (02/27/91)
Since Phil asked for people successfully using the 1.3/1.5 hybrid to give their impressions, I figured I'd toss mine in.. First off, getting the new system working is pretty much a snap if you use the instructions as a starting base. I say "starting base" because some things are both easier and more difficult that made out in the instructions. The ..<blah> links, for instance, appear to be superfluous - I couldn't find anything that subsequently referred to them. Similarly, various makefiles had to be changed in order to use the 1.5 includes properly if one wanted to be paranoid and not install any of the 1.5 stuff over 1.3 stuff until everything was thoroughly tested. All in all, however, it was very easy and the authors are to be commended. Good job, guys! The version of elvis that comes with the distribution (1.2) has quite a few more bugs than the latest version (1.4) and you're urged to get the latest rather than waste any time on 1.2. Elvis still fails to update the screen properly in some instances using the stock vt100 termcap entry (and completely tosses its cookies on the BSD one). If you're using things like elvis or more from an X terminal, you'll want to add support for the LINES and COLUMNS environment variables so that bigger screen sizes can be used (SIGWINCH? Don't make me laugh). The 1.5 TTY driver is a major improvement. I can actually kermit/zmodem at 38400 baud on several ports at once now. Major telecommunications enhancement! Using zmodem at 38.4K, you should expect around 3.2 K/Sec if your host computer is halfway fast. Definately makes formerly unrealistic transfers a complete breeze. The pipe code is losing. Many tools (or even simple things like "/lib/cpp ... | cat -s > foobar") will break. Jyrki's patch for multiplying the PIPE_SIZE constant in the kernel by 8 seems to work well. The recent patch for handling partial read/writes to pipes seems like a better solution, but I'm leary of it for now. I'm interested to know if anyone is using it successfully. The 64 meg partitions work as advertised. I've got 3 contiguous ones on my disk that work fine. The number of free inodes seems to be allocated a little on the high side (mkfs doesn't seem to be too intelligent about this), but aside from that, alles klar. Signal handling by the TTY driver still doesn't work %100 for me. I can interrupt a running make (eventually) with a keyboard generated interrupt, but something as simple as a "cat" just sits there and looks at me, no matter what I bang at it. Something is hosed there somewhere, methinks. What else... Hmmm. Can anyone tell me why a number of 1.5 include files do the following: #ifndef MY_INCLUDE_PROTECT #define MY_INCLUDE_PROTECT #ifndef SOME_OTHER_INCLUDE_PROTECT #include <its_safe.h> #endif ... #endif /* MY_INCLUDE_PROTECT */ Rather than simply including the file unconditionally and leaving it up to the included file to protect against multiple inclusion? That's the general convention, and much better than having files depend on each other's supposedly private "don't include me twice" macros. I've added fchmod() and fchown() to the kernel just for consistency. I also noticed that things like getw()/putw() .. getl()/putl() were missing so I added them too. Expect diffs soon. Anyone care to tell me why the message passing stuff between library and fs/mm is such an evil hack? There's some stuff I can understand as being necessary from the PC world, but the way formerly structured messages (which are a nice idea, fundamentally) are decomposed into multiple global macro names that the work procs are then supposed to just sort of know about is SICK. Why AST didn't simply decide to encode them into some sort of higher level message descriptor to which each and every work procedure would take a pointer to is beyond me. The way it currently works is about as counter-intuitive as one can get. Anyway.. I've gotten pretty sidetracked here.. Chalk it up to very very little sleep in the last 3 days due to not being able to stop playing with all of the above. Don't get me wrong folks, this is great fun! Never had a kernel I could compile in 5 minutes before.. Jordan