From owner-svn-src-all@freebsd.org Tue Dec 12 16:30:20 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE242E9E28F for ; Tue, 12 Dec 2017 16:30:20 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BAA58648DD for ; Tue, 12 Dec 2017 16:30:20 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: ba804217-df59-11e7-93a5-cd02e7dc7692 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id ba804217-df59-11e7-93a5-cd02e7dc7692; Tue, 12 Dec 2017 16:30:13 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBCGUHTZ001438; Tue, 12 Dec 2017 09:30:17 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1513096217.5897.52.camel@freebsd.org> Subject: Re: svn commit: r326773 - in head/sys: conf dev/syscon From: Ian Lepore To: rgrimes@freebsd.org, Emmanuel Vadot Cc: Alexey Dokuchaev , Nathan Whitehorn , Kyle Evans , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Tue, 12 Dec 2017 09:30:17 -0700 In-Reply-To: <201712121540.vBCFeLFZ086830@pdx.rh.CN85.dnsmgr.net> References: <201712121540.vBCFeLFZ086830@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 16:30:21 -0000 On Tue, 2017-12-12 at 07:40 -0800, Rodney W. Grimes wrote: > > > > On Tue, 12 Dec 2017 06:18:36 +0000 > > Alexey Dokuchaev wrote: > > > > > > > > On Mon, Dec 11, 2017 at 10:14:04AM -0800, Nathan Whitehorn wrote: > > > > > > > > I think this name might confuse people looking for "syscons". Can it be > > > > renamed? Also, if it is ARM-specific, maybe it belongs in sys/arm? > > > +1 for rename, it's very confusing now. > ++1 rename it or expect irrate users > > > > > > > > > > > > ./danfe > >  It's not confusing. The spec is clear it's named "syscon" so our > > driver must be named syscon, naming it otherwise would be confusing. > >  What's confusing is the directory name for "sc" named syscons, it's > > config options are named SC_* and the device is named sc. > The spec is wrong for dictating what any implementation must > call this, the spec does not own the implementation name space. > > It is called called syscons and uses the variables and driver > names sc beacuse that is what we did back in the 90's, drivers > typically had 2 character names. > > > > >  The only valuable remark in this thread is bde's one saying it's not > > documented etc ... and yes we do sucks in this area in the arm world. > Thank you for your dismissal of input from the community, does that > mean your gong to ignore them? > > > > >  Anyhow, I caught a discussion between mmel@ and kevans@ on IRC saying > > that we will move the driver into extres after adding some standard > > stuff common to extres framework. > FYI why is this so bad an idea to call it syscons: > man syscons > How do you plan to resolve that name space conflict? > AND this man page has existed since 1.0,  So 25 years of > finger memory, your just not gona do well trying to change that. > > So a driver named "syscon" that implements the FDT device named "syscon" is somehow a bad idea because it differs from an existing driver directory name by only one character, but you're not bothered by alc/ale, or bce/bfe/bge, or iwi/iwn, or mlx/mly, or any other of the literally dozens of existing drivers whose directory names differ by only 1 character. In addition you defend naming options related to "syscons" as "sc" because 25 years ago, "drivers typically have 2-character names", and I guess that fact magically connects "device sc" to "dev/syscons" in peoples' minds, because... phase of the moon, or what??? This whole discussion feels like it was scripted by Salvador Dali and produced by David Lynch. -- Ian