Date: Sat, 5 Apr 1997 13:21:13 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dfr@nlsystems.com (Doug Rabson) Cc: jkh@time.cdrom.com, dufault@hda.com, current@freebsd.org Subject: Re: Breaking the lkm DISPATCH macro Message-ID: <199704052021.NAA23542@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.95q.970405155123.8538F-100000@herring.nlsystems.com> from "Doug Rabson" at Apr 5, 97 03:54:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Does this mean that my OSS module will stop working? Sigh.. > > > > That brings up a very good point, which is that we need to start > > thinking about contacting vendors when we do stuff which will cause > > their stuff to break. I realize that everyone can't keep track of > > every single commercial product available for FreeBSD (not that it's > > exactly *hard* right now though :) and its dependencies, so all I'm > > asking is that if a user (like Doug here) raises an advance concern or > > we start getting bug reports from our early BETA customers WRT some > > commercial product, that should raise a *really big red flag* with us. [ ... ] > I totally agree. Developers ought to be *very* careful when changing > kernel data structures. I don't want to get too religious about back > compatibility (we aren't Windoze after all) but if a couple of minutes > thought can preserve binary compatibility, then it is a couple of minutes > well spent. This bolsters the case for seperability of kernel interfaces, so as to minimize the breakage that results when you *need* to change an interface. Right now there is a great deal of spaghetti in there, and it's only going to get worse so long as we continue to provide libkvm as an acceptable method of "interfacing". Any time we do that, we "define" a defacto interface that depends on the kernel data structures implementation, and frankly, we can't afford to make any kind of commitment that we will never change important kernel data structures. Binary compatability should be maintained where possible, but should be abandoned when maintaining compatability would criple good engineering changes. That said, I *do* think we've been a bit cavalier about changing the proc struct around without providing a standard interface to needed data through sysctl() or /proc. One of the major villans here is "ps" and family's historical ability to operate on system dumps, and the use of knowledge of the structure size as an iteration mechanism for determining active processes in the system. 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?199704052021.NAA23542>