dce@Solbourne.COM (David Elliott) (06/04/89)
I've done extensive work in the areas of system administration interfaces
and automation, and in the area of porting Unix commands.
Two items that I find particularly annoying are getting kernel data
values and handling system files.
The nlist interface to the kernel is a major hassle for a number of
reasons. First of all, I find that in a lot of development
environments, the kernel that is running is not /vmunix or /unix, but
is some other item. Secondly, people often want to know things like
the load average without having to make their programs setuid (or
worse, they get root permission and start playing system god without
having enough experience). Finally, sizes of data structures change,
yet there is no interface for getting these sizes, and in heavy
development environments, you can't even guarantee that your sys header
files match the kernel (or any kernel, for that matter). Programs like
ps would be a lot more useable in the face of kernel programmers if
this data were available at run-time.
In the area of system files, or more generally system data, there is a
problem of consistency. System file interfaces are sometimes designed
by people without any solid guidelines. It's hard to know whether or
not # denotes a comment, or whether a backslash at the end of a line
continues a line or not. This is confusing to people administering
systems, and leads to program failures more often than it should.
Also, I write lots of shell scripts, and I find it particularly
difficult at times to get to the system data, or to get it in a form
that is easy to digest. It would really help to have some programs for
querying and manipulating things like password and ttytab entries in
"batch mode", allowing people to develop various convenient interfaces
to these files.
Of course, the main thing is to get these things out into the world
where people will use them. It doesn't do a lot of good to
standardize if nobody adheres to the standards.
--
David Elliott dce@Solbourne.COM
...!{boulder,nbires,sun}!stan!dceusenet@cps3xx.UUCP (Usenet file owner) (06/05/89)
In article <1344@marvin.Solbourne.COM> dce@Solbourne.com (David Elliott) writes: >I've done extensive work in the areas of system administration interfaces >and automation, and in the area of porting Unix commands. > >Two items that I find particularly annoying are getting kernel data >values and handling system files. I agree. A better approach is the $GETSYI/$GETJPI calls found in VMS. They are complicated, and there may be better ways to organize the information they return, but: (1) They provide a fairly consistent interface for retrieving information. (2) They isolate my programs from system data structure changes. (3) They provide a point to implement security mechanisms. Anton (Warning: I'm biased, check my .sig) +---------------------------+------------------------+ | Anton Rang (grad student) | "VMS Forever!" | | Michigan State University | rang@cpswh.cps.msu.edu | +---------------------------+------------------------+
rmtodd@uokmax.UUCP (Richard Michael Todd) (06/06/89)
In article <1344@marvin.Solbourne.COM> dce@Solbourne.com (David Elliott) writes: >Two items that I find particularly annoying are getting kernel data >values and handling system files. Getting kernel data values isn't too much of a problem (once you master nlist and friends), though as UNIX is currently implemented it's extremely ugly. The main problem I seem to run into is figuring out just what kernel variable you need, what format it is in, and what it means once you've got it. The closest thing you find to documentation is groveling through /usr/include/sys and seeing if anything interesting seems to be useful. (Then you get to guess which other include files /usr/include/sys/whatever.h needs to have precede it. I've often wished for all include files to clearly state in a comment: NEEDS sys/types.h, sys/page.h, etc..) Anyway, what I'm saying is that to a large extent the existing kernel internals need to be documented. Granted, a better interface to reading kernel internal variables and structures would be nice, but unless the variables are documented it won't do you much good. >The nlist interface to the kernel is a major hassle for a number of >reasons. First of all, I find that in a lot of development >environments, the kernel that is running is not /vmunix or /unix, but >is some other item. Secondly, people often want to know things like >the load average without having to make their programs setuid (or >worse, they get root permission and start playing system god without >having enough experience). Finally, sizes of data structures change, Well, really such programs ought to be setgid kmem (or whatever group owns /dev/kmem), but still your point applies--it makes it impossible for Joe User to write such programs himself, and is a pain even for Joe Sysadmin. >yet there is no interface for getting these sizes, and in heavy >development environments, you can't even guarantee that your sys header >files match the kernel (or any kernel, for that matter). Programs like >ps would be a lot more useable in the face of kernel programmers if >this data were available at run-time. Agreed. It would be nice if there was an improved version of nlist that could read not only the address of the kernel data structure, but the type and size as well (presumably the kernel would be compiled with -g), and automatically read in the right amount of data. Of course, an even better approach is to have some system call to fetch kernel data yourself, without requiring that /dev/kmem be accessible. Encore has such a system call, called inq_stats; ps and its friends are implemented using inq_stats, and mere users can write their own ps-like programs for collecting data on processes. Of course, the flip side of this is that if you want some information that isn't one of the types inq_stats will give, you're SOL (e.g. as far as I and a friend of mine can tell, there's no way to tell from inq_stats data if a process is swapped out.) Still, such a call is useful. -- Richard Todd rmtodd@chinet.chi.il.us or rmtodd@uokmax.ecn.uoknor.edu aka ...!sun!texsun!uokmax!rmtodd "Never re-invent the wheel unnecessarily; yours may have corners."-henry@utzoo
mellon@zayante.pa.dec.com (Ted Lemon) (06/07/89)
rmtodd@uokmax.UUCP (Richard Michael Todd) sez: >Getting kernel data values isn't too much of a problem (once you master >nlist and friends), though as UNIX is currently implemented it's extremely >ugly. The main problem I seem to run into is figuring out just what kernel >variable you need, what format it is in, and what it means once you've got >it. Well, that's part of it. The other part is that thrashing through the kernel's name list takes a lot of time on small machines. It is highly undesirable to have to do this on a regular basis. On a typical small machine, doing a ps is an unbelievably slow operation. It really shouldn't be. Usually, when you do a ps, it's because the system is misbehaving, often because it's overloaded. The last thing you need is some mondo bizarro program that thrashes through the kernel's name list and brings the CPU to its knees in the process. _MelloN_
dce@Solbourne.COM (David Elliott) (06/07/89)
In article <3307@uokmax.UUCP> rmtodd@uokmax.UUCP (Richard Michael Todd) writes: >In article <1344@marvin.Solbourne.COM> dce@Solbourne.com (David Elliott) writes: >>Two items that I find particularly annoying are getting kernel data >>values and handling system files. > Getting kernel data values isn't too much of a problem (once you master >nlist and friends), though as UNIX is currently implemented it's extremely >ugly. Neither is programming a 6502, but luckily we don't have to program them. The whole point of my posting was to point out an area that could use some improvement, and GNU is all about improving Unix. As far as it not being that much of a problem, it is, as I pointed out a problem if the kernel you are running is not the same as the one that you ask nlist to look at. > Granted, a better interface to reading kernel internal variables and >structures would be nice, but unless the variables are documented it >won't do you much good. Agreed. If the interface were, for example, a system call made specifically for getting this type of kernel data, you'd have to document it. Hopefully, you could even make some of it standard (load average, for example). Also, why not have such an interface? Nlist really doesn't give you much of an advantage, and it's really gross to have to go reading symbols out of a file, and then (sometimes) masking the address, and then reading it. Why not go ahead and implement a standard, simple interface? >Well, really such programs ought to be setgid kmem (or whatever group >owns /dev/kmem), but still your point applies--it makes it impossible for >Joe User to write such programs himself, and is a pain even for Joe Sysadmin. No, they should not "ought" to be, they "must" be. This is because /dev/kmem is a security hole. For years, /dev/mem was readable by everyone, and people, like the authors of various Emacs variants, used that. I'll argue that /dev/kmem is more of a security hole now than ever. I've seen two cases in the last year in which someone changed /dev/kmem to be readable by everyone because of some free software needing to use it. There are a lot of people who don't know it's a security hole, so people start using it. -- David Elliott dce@Solbourne.COM ...!{boulder,nbires,sun}!stan!dce
chris@mimsy.UUCP (Chris Torek) (06/07/89)
In article <MELLON.89Jun6170722@zayante.pa.dec.com> mellon@zayante.pa.dec.com (Ted Lemon) writes: >... The other part is that thrashing through the kernel's name list >takes a lot of time on small machines. ... On a typical small machine, >doing a ps is an unbelievably slow operation. Actually, under 4.2BSD on a VAX 11/785---which might not be a typical small machine, but I did profile /bin/ps---the slowest part was grubbing through /dev to figure out what to print for `tty'. As I recall, reading symbols out of /vmunix was fairly far down the list. Under 4.3BSD-tahoe, ps reads the file /etc/psdatabase for this information; psdatabase is built at boot time by running `ps -U' from /etc/rc. If you make new terminal devices, you must rerun `ps -U'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
guy@auspex.auspex.com (Guy Harris) (06/08/89)
>Well, that's part of it. The other part is that thrashing through >the kernel's name list takes a lot of time on small machines. It is >highly undesirable to have to do this on a regular basis. In which case perhaps "ps" should somehow cache the results of a scan through the name list (and through "/dev", etc.) - as both the 4.3BSD and later S5 versions do.