From owner-svn-src-all@FreeBSD.ORG Fri Mar 14 17:26:50 2014 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D39B6F9; Fri, 14 Mar 2014 17:26:50 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3216A81B; Fri, 14 Mar 2014 17:26:49 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2EHQm6G048337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2014 10:26:48 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2EHQmDt048336; Fri, 14 Mar 2014 10:26:48 -0700 (PDT) (envelope-from jmg) Date: Fri, 14 Mar 2014 10:26:48 -0700 From: John-Mark Gurney To: Christian Brueffer Subject: Re: svn commit: r263110 - head/share/man/man4 Message-ID: <20140314172648.GU32089@funkthat.com> References: <201403131619.s2DGJax1071196@svn.freebsd.org> <4D0B04BD-4EF6-4963-941E-012B81F8DFAB@jnielsen.net> <20140314015438.GO32089@funkthat.com> <5322C83F.6060109@FreeBSD.org> <20140314164107.GS32089@funkthat.com> <933F8270-90C1-4AFE-9F39-A7ADBC05C772@bsdimp.com> <53233477.7060400@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53233477.7060400@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 14 Mar 2014 10:26:48 -0700 (PDT) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, John Nielsen , src-committers@FreeBSD.org, Warner Losh X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 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: Fri, 14 Mar 2014 17:26:50 -0000 Christian Brueffer wrote this message on Fri, Mar 14, 2014 at 17:55 +0100: > On 3/14/14 5:47 PM, Warner Losh wrote: > > > > On Mar 14, 2014, at 10:41 AM, John-Mark Gurney wrote: > > > >> Warner Losh wrote this message on Fri, Mar 14, 2014 at 08:30 -0600: > >>> On Mar 14, 2014, at 3:13 AM, Christian Brueffer wrote: > >>> > >>>> On 3/14/14 2:54 AM, John-Mark Gurney wrote: > >>>>> John Nielsen wrote this message on Thu, Mar 13, 2014 at 16:28 -0600: > >>>>>> On Mar 13, 2014, at 10:19 AM, John-Mark Gurney wrote: > >>>>>> > >>>>>>> Author: jmg > >>>>>>> Date: Thu Mar 13 16:19:36 2014 > >>>>>>> New Revision: 263110 > >>>>>>> URL: http://svnweb.freebsd.org/changeset/base/263110 > >>>>>>> > >>>>>>> Log: > >>>>>>> remove link to the missing AMD Geode LX SB man page... we can add it > >>>>>>> back once someone cares enough to write one.. > >>>>>> > >>>>>> You mean like this one? > >>>>>> http://svnweb.freebsd.org/base/head/share/man/man4/man4.i386/glxsb.4 > >>>>> > >>>>> The problems of checking on an amd64 box... :( > >>>>> > >>>>> Actually, how are we suppose to handle links to arch dependant man > >>>>> pages in arch independant man pages? I did this check on an amd64 box, > >>>>> so the page glxsb didn't get installed... Should we just always > >>>>> install these man pages on all arches then? Or are we fine w/ > >>>>> references to non-existant pages (on some arches)? > >>>>> > >>>>> Or should glxsb.4 be moved to an arch independant dir? > >>>>> > >>>> > >>>> I wonder if it makes sense to keep arch-dependent man directories at > >>>> all. I.e., if I prepare an ARM disk image on my amd64 laptop, I really > >>>> want to have the arm manpages available on that amd64 box. > >>>> > >>>> Does anyone see a reason not to move man4/man4.${ARCH}/*.4 to man4? > >>>> We're talking about 60 manpages here, so space is not really an issue. > >>> > >>> Historically there was the separation because xp on one platform might be > >>> radically different from xp on another platform. The other reason was confusion > >>> because it wasn?t always clear if device foo actually worked on platform X. > >> > >> We have less of that issue now, but it could still be.. but issues like > >> that can be addressed other ways, though kernel config, release notes, > >> etc.. I doubt people use manpages as a guage if a device worked on > >> their arch... Plus, if the device is shared and known not to work on > >> a specific arch, that should be listed in the BUGS section of the man > >> page.. :) > > > > Yea, kinda my point :) > > > >>> Do we have any collisions like that? If so, we need to resolve those first. > >> > >> Doesn't look like it... > >> $ grep ^_ Makefile | sed -e 's/.4.*//' | wc -l > >> 86 > >> $ grep ^_ Makefile | sed -e 's/.4.*//' | sort -u | wc -l > >> 86 > >> > >> It's also telling that besides i386 and amd64 specific man pages, we > >> only have one mips specific man page in man4? > > > > True enough, I hadn?t looked... > > > >> This won't address the other man pages for arch specific utilities > >> and libraries though, like sunlabel? > > > > True, but those are niche things, so it is less important :) > > > >>> Also, it would be good to tag the ones that are arm specific as such somehow. > >> > >> Should we just tag the pages w/ a section listing relevant architectures, > >> or break the beauty of single digit section numbers and do 4.i386? > > > > Tag in the man page itself, either in its own unique section, or in BUGS. > > > > We kinda maintain some of this information already (albeit I'm not sure > how accurate it is) in the hardware notes. The hardware notes > themselves are generated from the HARDWARE sections of the manpages, > while the arch information is in > src/release/doc/share/misc/dev.archlist.txt. > > One possibility would be to generate this file from an ARCHITECTURE (or > the like) section in section 4 manpages, the same way as we to with > HARDWARE sections. This becomes a little troublesome to handle all the corner cases that can be expressed, and what do we want to say... There is if the code has been tested or not, and just how arch specific it is... Pretty much all of our supported platforms support PCI, and therefor ISA through a bridge, which means all the "i386" specific ISA cards could possibly find themselves on non-i386 machines... Now if they'll work due to endian issues or other issues or not is another issue entirely... Some of the entries in dev.archlist.txt don't match what you can build per sys/conf/files*... aic's pccard is available to all, it's isa is only to i386 and pc98, but listed as i386, pc98 and amd64... so we end up w/ an odd set here, that isn't very easy to figure out and parse... Do we want a list of expected working and tested working? Then we also might want to list known not working configurations too... I know too much about how to hack to get crazy hardware to work where it isn't suppose to, so other people w/ clearer heads on this topic should make these decisions... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."