paul@FLEETWOOD.CC.UMICH.EDU ('da Kingfish) (06/18/87)
Renu Raman asks: "I am no UNIX guru and so would like to know what's wrong in using /dev/kmem" I think we (those of us who don't like using /dev/kmem even if we have one on the system) say something like "procedural interfaces are nicer than having to know about data structures." In a dream, I received the revelation that people who use /dev/kmem will be reincarnated as rocks. --paul
bobr@zeus.UUCP (06/19/87)
In article <8706181935.AA01574@fleetwood.cc.umich.edu> paul@FLEETWOOD.CC.UMICH.EDU ('da Kingfish) writes: >"I am no UNIX guru and so would like to know what's wrong in >using /dev/kmem" I think we (those of us who don't like using /dev/kmem even if we have one on the system) say something like "procedural interfaces are nicer than having to know about data structures." It's fine to say that procedural interfaces are safer and provide a more insular wall between a changing kernel and the applications which it supports -- as long as those procedural interfaces are provided to the user. To my knowledge, albeit limited on this subject, there is no documentation from Apollo in the procedural interfaces to support such a program as ps(1). I happen to prefer the output of sps, a public domain version of ps, but I have no possibility of porting it without knowing this interface. I agree that /dev/kmem is a hackers delight but a system developer's nightmare. However, having access to /dev/kmem (and adequate documentation on the system tables of interest) provides at least some means of obtaining the desired information, which is better than no means at all. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
lid@cernvax.UUCP (lid) (06/21/87)
In article <1894@zeus.TEK.COM> bobr@zeus.UUCP (Robert Reed) writes: >In article <8706181935.AA01574@fleetwood.cc.umich.edu> paul@FLEETWOOD.CC.UMICH.EDU ('da Kingfish) writes: > > >"I am no UNIX guru and so would like to know what's wrong in > >using /dev/kmem" > > I think we (those of us who don't like using /dev/kmem even if we have > one on the system) say something like "procedural interfaces are nicer > than having to know about data structures." > >It's fine to say that procedural interfaces are safer and provide a more >insular wall between a changing kernel and the applications which it >supports -- as long as those procedural interfaces are provided to the user. > >To my knowledge, albeit limited on this subject, there is no documentation >from Apollo in the procedural interfaces to support such a program as ps(1). Even worse than that, Apollo does not provide any procedural interface to their network, or to the process management procedures etc. Try for instance to write a server,using only the Aegis released procedures, that provides some network service and try to contact it without knowing on which machine it is running. There is no way to do that in a clean way (i.e. without using files to store information about location of server etc.) Or try to name a process from the process itself, or try to send a fault from one process to another, or try to know from which partner a given node is booting from etc. I think procedural interface is fine, as long as you get it ! A. Petrilli