gnu@hoptoad.uucp (John Gilmore) (11/11/86)
In article <464@cdx39.UUCP>, jc@cdx39.UUCP (John Chambers) writes: > ...if you tell it to use "/dev/kmem", it > will change the name of the live system. > > This is a nice example of moving a "system hook" out > of the kernel and into user space, thus making the > kernel smaller and simpler. (The concept does tend > to horrify many people, good system design though it > may be. :-) Moving "system hooks" out of the kernel into user space is a good idea. But if you make the interface to the "hook" unclean and unportable in the process, then it's a bad implementation of the good idea. What horrifies people like me is that many uncultured people will write the bad implementation and think it's good. Many of these make it into products and this is even worse since it means thousands of people will have to live with this cruddy unportable interface, all because somebody got a "good idea" but didn't have the talent or the judgement about when to use it. Writing to /dev/kmem is like using peek and poke in micro Basics. You know it works, but you know damn well that this program will not work on a different brand of computer. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa "I can't think of a better way for the War Dept to spend money than to subsidize the education of teenage system hackers by creating the Arpanet."
sjm@dayton.UUCP (Steven J. McDowall) (11/12/86)
In article <1279@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > ... >Writing to /dev/kmem is like using peek and poke in micro Basics. >You know it works, but you know damn well that this program will not >work on a different brand of computer. >-- If (yes, a big one here :-) the programmer did it at ALL half way carefully, then the code is almost garunteed to be portable at least in the same family of operating systems. (Ie. sys5 to sys5, I am not sure about BSD since I don't use it). SYS5 has a standard routine called nlist() (3C) which given a list of variable names, and a unix kernel, it will return the address offset in kmem where that variable is located. Now you can open kmem, seek to the correct position, and update. Not as bad as you would want us to believe, and VERY useful. -- Steven J. McDowall Dayton-Hudson Dept. Store. Co. UUCP: ihnp4!rosevax!dayton!sjm 700 on the Mall ATT: 1 612 375 2816 Mpls, Mn. 55408
jc@cdx39.UUCP (John Chambers) (11/18/86)
> ... Many of these > make it into products and this is even worse since it means thousands > of people will have to live with this cruddy unportable interface, > all because somebody got a "good idea" but didn't have the talent or > the judgement about when to use it. > > Writing to /dev/kmem is like using peek and poke in micro Basics. > You know it works, but you know damn well that this program will not > work on a different brand of computer. > While I agree with the sentiment in the abstract, I'd like to point out that in this particular case, you are wrong. Before posting the source, I tested it on a number of different brands of computer. It worked just fine on all but one. The one where it failed turned out to have a bug in the memory device driver; setuname died with an I/O error while trying to read /dev/kmem. So I used it on /unix, which worked just fine, and re-booted. This is arguably not a case of non-portability. If someone were to market a version of Unix (tm) in which, say, printf("%X") bombed out, you wouldn't claim that programs using this aren't portable. You'd say that the particular release of that system has a bug. Similarly, if someone tries using on a system (Unix or other) that lacks the utsname structure or system call, it won't work. It'll probably not even compile. It also won't port to a system that lacks read() and write(). So what? As for the original flame, well, I agree that Unix doesn't have the best way of handling peeking and poking into the kernel. There should be a set of files somewhere that correspond to the kernel's tables, so that programs can just open a table. My little program wastes time needlessly scanning through the kernel looking for utsname. It would be much cleaner and faster if there were a file named something like "/kernel/utsname" to open. I've heard rumors that there are some versions of Unix where this is done, but it's certainly not standard. There should also be a file "/proc/12345" whose contents are the (virtual) address space of process 12345. This would make it possible to write at least semi-portable versions of things like ps, not to mention debuggers. Again, I've heard rumors that such things have been done (and it wouldn't be too hard), but it's certainly not very common. If there's someone around that wants to build a Unix that does these things, I'd be happy to send them my resume. I'd rather work on making things work right than just flame about how bad it all is. Meanwhile, we do what we can with what still isn't the OS to end all OSs, and sometimes remind ourselves that we could be stuck working on OS/MVS. -- John M Chambers Phone: 617/364-2000x7304 Email: ...{adelie,harvax,inmet,mcsbos,mit-eddie,mot[bos],rclex}!cdx39!{jc,news,root,usenet,uucp} Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193 [The following added so that an NSA computer will take notice, guaranteeing that I'll have at least one reader:-] > cryptography, cipher, DES, homosexual, drugs, secret, decode, NSA, CIA, NRO, terrorist, Soviet, Libya, Iran.
sewilco@mecc.UUCP (Scot E. Wilcoxon) (11/21/86)
> Writing to /dev/kmem is like using peek and poke in micro Basics. > You know it works, but you know damn well that this program will not > work on a different brand of computer. The reason PEEK and POKE are used in micro BASICs is because there sometimes is no other way to do the job on that machine. I had to write the first downloader to our APPLE IIs in BASIC because it was simply much easier than doing it in mini-assembler. Then downloaded the hex of the downloader from the cross-compiler on the Cyber and that was that. Back in the UNIX world, one of my first experiences with 'adb' was to change the name of the nodename in the kernel. SCO didn't think anyone would want to relink the XENIX kernel on the Apple Lisa, so I got to discover adb bugs on the kernel. This little program would have helped (as it was, I got four revisions of the kernel and wrote an equivalent program so my site would stop becoming "xenix"). -- Scot E. Wilcoxon Minn Ed Comp Corp {quest,dayton,meccts}!mecc!sewilco (612)481-3507 sewilco@MECC.COM ihnp4!meccts!mecc!sewilco "Can you stop yourself from hitting the dashboard unbelted at 30 MPH? Can you fall off a three-story building and land safely? 32 ft/sec."