From owner-freebsd-chat Wed Jun 3 09:12:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07974 for freebsd-chat-outgoing; Wed, 3 Jun 1998 09:12:40 -0700 (PDT) (envelope-from owner-freebsd-chat@FreeBSD.ORG) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA07968 for ; Wed, 3 Jun 1998 09:12:33 -0700 (PDT) (envelope-from Mailer-Daemon@East.Sun.COM) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA07940 for ; Wed, 3 Jun 1998 09:12:03 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id MAA14414; Wed, 3 Jun 1998 12:11:59 -0400 Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id MAA26950; Wed, 3 Jun 1998 12:11:58 -0400 Received: (from alk@localhost) by compound.east.sun.com (8.8.8/8.7.3) id LAA29012; Wed, 3 Jun 1998 11:13:37 -0500 (CDT) Date: Wed, 3 Jun 1998 11:13:37 -0500 (CDT) Message-Id: <199806031613.LAA29012@compound.east.sun.com> From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn Reply-To: alk@pobox.com To: chat@FreeBSD.ORG Subject: Re: kernfs/procfs questions... References: <199806031145.EAA26532@hub.freebsd.org> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm pretty strongly on the side of simplicity and orthogonality of use, and universal applicability of tools myself. That's what the FS interface provides, and sysctl, or IP services for that matter, fail to provide. (Who goofed with sockets?) The FS interface needs to be abstracted, generalized in order to accomodate these broader applications, admittedly. Ioctls are eggregious. I can understand the performance consideration which leads to SHM, but in general communication between processes should be accomplished by read/write, not ioctl and setsockopt and listen and accept and sysctl and traps, and... One could argue for substantial changes in many historical interfaces, but codebase and portability considerations generally prohibit such changes in any general-purpose system. FreeBSD, however, seems to draw the line by historical reference to 4.4 Lite 2, constraining the system more strongly than does the application codebase (since the former includes design decisions which are not honored by the latter). This is unfortunate when it causes divergence from the mainstream application codebase, which is more Linux/SVR4- oriented with each passing day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message