Date: Tue, 15 Apr 1997 11:42:08 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: haas@willi.lion.de (Christoph Haas) Cc: terry@lambert.org, chris@acme1.ruhr.de, dennis@etinc.com, freebsd-hackers@FreeBSD.ORG, haas@lion.de Subject: Re: Commercial vendors registry Message-ID: <199704151842.LAA22888@phaeton.artisoft.com> In-Reply-To: <Pine.SOL.3.96.970415115005.3832B-100000@willi> from "Christoph Haas" at Apr 15, 97 11:53:27 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > A big part of this is, IMO, taking care to not break things unnecessarily, > > either by not exposing the internals of things we intend to change, or > > not changing the things for which we have exposed internals. > > Agreed, but isn't most of FreeBSD "exposed internals" ? Whoever wants to > can read in the sources looking at how things are implemented. And if he > relies on those internals instead of defined interfaces to certain > services, he can be sure that his code breaks next time someone commits a > change to these internals. That's a different kind of dependency. --- Begin "Old Hacker" shaggy dog story... It's what we used to call "ice fishing" Back In The Good Old Days of hacking, before you had real system source code. You'd "just know" that calling a combination of calls in a particular order would achieve the results you wanted because you saw code that did it and copied what it did. The most well known example of this was the "partial open hack", where you opened a modem control device with O_NDELAY to get it open without DCD being raised, then you did an open without O_NDELAY to get an open without the non-blocking I/O (which you could not turn off, in those days), then you closed the first descriptor. It's very much like ice fishing from two holes with two hooks... Another example was the old "cu" replacements before there was a select or poll call, which used to fork and establish a "reader" and a "writer" process to get two way communication between your terminal and the device. They all broke with the partial open hack after uugetty was introduced (SVR3 uugetty, not SCO uugetty). The new uugetty set O_EXCL on the open, and the partial open hack would bypass the code that would reset it, and the fd would fail to live past the fork (because O_EXCL means only one process could have it open). You had to reset the O_EXCL by doing a blocking open without O_EXCL. So you did a blocking open without O_EXCL, alarmed out of it after one second, and then went into the partial open hack. Life was complicated back then. --- End "Old Hacker" shaggy dog story... The "exposed internals" I was referring to are the internals where the interface is not abstracted from the representational format of the data. The program "ps" is a prime example, as is any program which needs the information it provides, and doesn't popen "ps" to get it. The "ps" program use libkvm to grovel around in the data space of the running kernel. It iterates the active processes, using its knowledge of the size of the proc structure, and several other nasty things which make it highly dependent on the size of a number of kernel data structures not changing. This is especially bad, because the interface for iterating the processes didn't have to be implemented in a struct size dependent way. Applying my maxim, either the proc structure size dependency should not be exposed in the iteration interface, or the size of a struct proc should never be changed. Note: since it's unreasonable to freeze the proc structure, since it would prevent much future progress, the correct application would be to seperate the iteration interface. Eventually, you would want to make such grovelling technically difficult to implement, so that it was rarely, if ever, done. So eventually, you want to get rid of libkvm entirely, and go to functional interfaces (like /proc and sysctl) to get the information. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704151842.LAA22888>