From owner-freebsd-arch Tue Nov 16 19:22:15 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4C79214A16 for ; Tue, 16 Nov 1999 19:22:06 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA04699 for ; Wed, 17 Nov 1999 04:22:01 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA53740 for freebsd-arch@freebsd.org; Wed, 17 Nov 1999 04:22:01 +0100 (MET) Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id B739E14E84 for ; Tue, 16 Nov 1999 19:20:46 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id UAA20961; Tue, 16 Nov 1999 20:20:20 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAA5maW3O; Tue Nov 16 20:20:14 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id UAA07079; Tue, 16 Nov 1999 20:20:25 -0700 (MST) From: Terry Lambert Message-Id: <199911170320.UAA07079@usr08.primenet.com> Subject: Re: cvs commit: src/sys/i386/include signal.h To: cracauer@cons.org (Martin Cracauer) Date: Wed, 17 Nov 1999 03:20:25 +0000 (GMT) Cc: marcel@scc.nl, cracauer@cons.org, bde@zeta.org.au, freebsd-arch@freebsd.org In-Reply-To: <19991115115552.A27870@cons.org> from "Martin Cracauer" at Nov 15, 99 11:55:52 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I moved this to -arch, since we have to make some long-term decisions > here: > > 1) Does FreeBSD prefer to pass information like this as unnamed array > of bytes or as structs with proper fields? As an observer... I think any time there is a contract between the kernel and user space about the layout of a field, it's evil. There are a lot of data interfaces that exist which are very, very bad for the stability of software over upgrades (e.g. "ps", "netstat", et. al.). That said, I think "signal" is an exception in this case, so if there is going to be a data interface for signal, and you are going to reorganize it, at least put a version number field in so that you can do backward compatability the right way (or "at all", for that matter). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message