From owner-freebsd-hackers Wed Mar 26 19:31:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA29387 for hackers-outgoing; Wed, 26 Mar 1997 19:31:57 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA29381 for ; Wed, 26 Mar 1997 19:31:54 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA29687; Wed, 26 Mar 1997 20:15:52 -0700 From: Terry Lambert Message-Id: <199703270315.UAA29687@phaeton.artisoft.com> Subject: Re: how to name fs specific programs To: jonathan@DSG.Stanford.EDU (Jonathan Stone) Date: Wed, 26 Mar 1997 20:15:51 -0700 (MST) Cc: terry@lambert.org, cjs@portal.ca, sommerfeld@orchard.east-arlington.ma.us, perry@piermont.com, hackers@freebsd.org, port-i386@netbsd.org In-Reply-To: <199703270146.RAA21224@Pescadero.DSG.Stanford.EDU> from "Jonathan Stone" at Mar 26, 97 05:46:09 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > if two trivial, syntactic details -- using "_" vs > /" as separators, and the endian-ness of the name components on either > of the separator -- are such show-stoppers for your scheme, then I > would be surprised if anyone here wants it. Correction: 1) "/" is a path component seperator, not a syntactic seperator internal to a path component. 2) "Endianess" is a non-issue, given #1 above. The issues are: o Should the per-FS commands be placed in a per-FS directory so that they can be treated as a unit instead of a pattern matching a list of files o If they should be places in a per FS directory, isn't adding a type value to the per-FS command name: o unnecessarily redundant o restrictive on the ability to switch between the "generic" and "boot fs specific" commands without modifying startup stripts and other hard coded paths, both now and in the future I want a design which is not restrictive on how a given FS component is implemented, instantiated, or used. I prefer (but do not demand) a design which is not unnecessarily redundant. > >only your opinion on implementation details > > You've had my opinion. If you don't like it, feel free to ignore it. You have only offered opinions on the design details, but without apprehension (you continue to state that you do not see the reason for the design); until you apprehend them, your opinion on them isn't applicable. I would like to help your opinion to be applicable, if you choose to continue to offer it. > >(assuming you are a competent coder). > > You might also consider dropping the unwarranted personal shots about > someone's competence, simply because they have the temerity to > disagree with you. I don't anyone ever looks good doing that. This is not an aspersion on your competence. This is a statement that even if you do not choose to apprehend the design details so that you can offer applicable opinions on the design, I would still value your opinions on implementation details. > I've already asked if we can let this slide. Can't we do that? I understand that you can't see the purpose behind the design; if you will stop objecting to the act of designing (despite of whether or not you personnally feel it to be purposeful), I'll be happy to let this side-bar discussion drop. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.