culberts@hplwbc.hpl.hp.com (Bruce Culbertson) (09/15/90)
Hi Gang, I would like to offer some opinions about how to live happily with Minix. If they make sense to you, great -- if not, then ignore them. Having a version of Minix which is different from any standard one is a pain. Sometimes it is hard to incorporate fixes from the standard version. Sometimes it is hard to even figure out what those fixes do because diff produces an avalanche of text. Applying a major upgrade is really time consuming. You can do things to minimize these problems. I strongly recommend that you do not make frivolous changes. Do not change the indenting. Do not fix spelling mistakes. Do not add comments (or, if you do, put them in a README file). Do not add things which do not add substantial and necessary function. Write a new command rather than modify one that isn't broken. Since none of us is Andrew Tanenbaum, we would each have written Minix differently. However, if we can try to think like him and adapt his style and philosophy, then our version of Minix will stay much more manageable and coherent. -------------------------------------------------------------------- Ok, off the soap box. Sorry for pontificating. You will notice that I have broken many of these guidelines -- but that's how I learned that they were good guidelines. I think the porting style which I am using in 1.5.10 is an improvement. Speaking of which, I have been busy with non-Minix things and I am not finished with 1.5.10. Unfortunately, I am leaving on vacation today for two weeks. Shortly after my vacation, I leave on a business trip. Hence, I will not finish 1.5.10 for a while. I have been using a Minix version which consists of 1.5 versions of MM and FS, and a slightly modified 1.3 kernel. If I can possibly find the time, I will try to post cdiff's for these against standard 1.5 PC-Minix. This will be for the benefit of real die-hard experimenters since I will not have the time to enumerate the library and command changes which should be used with it (even though there really are not too many). Undoubtedly others will want to try the 1.5 upgrade and it would be a shame to duplicate my effort on FS and MM. -------------------------------------------------------------------- Here are some comments on recent pc532 postings. I really like Johan's /dev/rtc. Good comments have been made on the pro's and con's of making the /dev/rtc format hardware dependent or hardware independent. I think I am most persuaded by the hardware independent argument, though. Some very small nits about Johan's posting: I am not as keen on /dev/rom since I do not see what I would use it for. I would have preferred that /dev/rtc and /dev/rom were posted as separate cdiff's so I could pick and choose. Also, I suggest disabling interrupts while the cache is disabled since we do not want a context switch and another process run before we turn the cache back on. For the "style" reasons I gave above, I would prefer to keep our date command unmodified. If we use a hardware dependent /dev/rtc, lets have a separate command to convert its format to date's format. Date is a nice small and functionally atomic command in the style that Ken Thompson has always advocated. I really like the idea of having the rtc and the system time completely decoupled except for user commands which can be run to set one from the other. Dave Rand has fixes for the tty bugs (well, at least the bugs we know about) that cause problems when multiple lines are being used. Bravo! Also, I like the new library code. I could easily change the assembler to use nop's for .align padding in the text segment. Keep at it, everyone. This is great! Bruce
news@daver.bungi.com (09/15/90)
Regarding /dev/rtc, and what format it should take. Under SCO (xenix and unix), /dev/clock, when read, will return something like: 0914154990 (for Fri Sep 14 15:48:32 EDT 1990) (I just did a ~r /dev/clock). There is also a program called setclock, which take a parameter of the format MMddhh[yy]. Which can be gotten via 'date +%m%H%M[%y]'. (If the argument is not present, it essentially does a 'cat /dev/clock'.) Oh, yeah: setclock sets the clock, of course. Note, btw, that there is no seconds in the /dev/clock input or output (a deficiency, IMHO). Anyway, just some prior art. Sean.