From owner-freebsd-current@FreeBSD.ORG Tue Jul 1 21:30:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8F47106566C for ; Tue, 1 Jul 2008 21:30:11 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3E73C8FC22 for ; Tue, 1 Jul 2008 21:30:10 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 9A484A06F2; Tue, 1 Jul 2008 23:30:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 8D4E2A06F1; Tue, 1 Jul 2008 23:30:07 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 5A616A06E8; Tue, 1 Jul 2008 23:30:06 +0200 (CEST) Received: from wep4017.physik.uni-wuerzburg.de ([132.187.37.17]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.1HF110) with ESMTP id 2008070123300575-95452 ; Tue, 1 Jul 2008 23:30:05 +0200 Received: by wep4017.physik.uni-wuerzburg.de (sSMTP sendmail emulation); Tue, 1 Jul 2008 23:30:05 +0200 From: "Alexey Shuvaev" Date: Tue, 1 Jul 2008 23:30:05 +0200 To: Marcel Moolenaar Message-ID: <20080701213005.GA94030@wep4017.physik.uni-wuerzburg.de> References: <20080701181358.GA93601@wep4017.physik.uni-wuerzburg.de> MIME-Version: 1.0 In-Reply-To: Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.1HF110 | April 11, 2008) at 07/01/2008 11:30:05 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.1HF110 | April 11, 2008) at 07/01/2008 11:30:07 PM, Serialize complete at 07/01/2008 11:30:07 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: freebsd-current@freebsd.org Subject: Re: puc(4) man page update? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2008 21:30:11 -0000 On Tue, Jul 01, 2008 at 01:02:32PM -0700, Marcel Moolenaar wrote: > > On Jul 1, 2008, at 11:13 AM, Alexey Shuvaev wrote: > >> - I have spent few hours figuring out why serial interfaces >> covered by puc(4) do not come up at boot time. The issue was I tried >> to use kernel module instead of compiling puc(4) into the kernel. >> Will it be good to have explicit note about it in the man page? > > Well, no. There's a very simple rule: > > If driver C is a child of a driver P and driver P is > loaded as a module, then driver C must be loaded as > a module as well. > > In this case uart(4) and ppc(4) are children of puc(4) > and both are compiled into the kernel by default. So, > you must either compile puc(4) into the kernel or > build uart(4) and puc(4) as modules as well. > > In other words: there's no problem with puc(4) being > loaded as a module. It's a generic problem with our > modules vs. compiled-in case. > Ok, clear now. The GENERIC kernel contains both sio(4) and uart(4) but not the puc(4). In this sense it is "wrong" (which is the cost for removing rarely used puc(4) out of the GENERIC kernel). >> - First time when I rebuilt the kernel I only added >> options COM_MULTIPORT, which is used inside sio(4). The puc(4) also >> states >> the serial ports are managed by sio(4). However it seems that serial >> ports are actually handled by uart(4). Is COM_MULTIPORT kernel option >> obsolete? > > COM_MULTIPORT is specific to sio(4), so yes it's obsolete. > > puc(4) favors uart(4) over sio(4), because both puc(4) and > uart(4) implement the serdev I/F, which gives puc(4) better > control over which port gets to service what interrupt > condition in what relative order. In other words, it allows > puc(4) to handle all receive interrupts of all ports before > it handles any transmit interrupts. > > With sio(4) there's no benefit. > So, one can still use puc(4) + sio(4) (by removing, for example, uart(4) from the kernel)? Then COM_MULTIPORT is not 100% obsolete yet. >> Attached is a draft of a patch to share/man/man4/puc.4 but maybe more >> work is required (regarding COM_MULTIPORT and sio(4) man page...). > > I would not mention COM_MULTIPORT in the puc(4) manpage > at all. Neither sio(4)... > I thougt about removing COM_MULTIPORT from the sio(4) both man page and source code. If one can still use it, let it be so. >> - The puc(4) man page states parallel ports are not supported yet. >> It seems thay did now. > > Parallel ports are supported, yes. > That's good! Attached is updated patch to puc man page. Don't know if it is really worthwhile. Thanks, Alexey.