Date: Tue, 27 Mar 2001 11:03:59 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Greg Lehey <grog@lemis.com> Cc: Mike Smith <msmith@freebsd.org>, Poul-Henning Kamp <phk@critter.freebsd.dk>, John Baldwin <jhb@FreeBSD.org>, <leclercn@videotron.ca>, <freebsd-alpha@FreeBSD.org> Subject: Re: dev_t size mismatch kernel / userland Message-ID: <Pine.BSF.4.33.0103271058070.33398-100000@herring.nlsystems.com> In-Reply-To: <20010327100548.D40349@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Mar 2001, Greg Lehey wrote: > >> The other issue is that exporting expurgated versions of kernel > >> structures is expensive. We've been exporting the unexpurgated > >> versions for years elsewhere, for example--see the proc size mismatch > >> messages from ps(1). That got fixed, not because it was "unclean", > >> but because it was a bloody nuisance. Yes, it's "clean" not to export > >> mutexes and dev_ts and friends, but it requires a fair amount of code > >> to do it, and it requires two structures which need to be kept in > >> sync. Exporting them doesn't do any harm that I can see. I don't > >> think that it's self-evident that you need to go to this much trouble. > > > > You basically shoot your own argument dead here. > > Your unsubstantiated claim. > > > Don't export private data structures to userland. End of story. 8) > > No, categorical statements prove nothing. The point is that this structure is part of the ABI between kernel and user parts of vinum. By exposing implementation details in the ABI, you are inevitable making the ABI more fragile, with potential knock-on problems when kernel and user parts get out of sync. In my opinion, all APIs should be defined as clearly as possible without emdedding any implementation details if at all possible. Structures in APIs should be designed carefully and used sparingly since they are the single largest cause of ABI breakage. Efficiency concerns are only relavent if the API must be particularly fast - I don't think this is the case here. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.33.0103271058070.33398-100000>