From owner-freebsd-usb@FreeBSD.ORG Wed May 25 19:34:41 2011 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ED7610656EA; Wed, 25 May 2011 19:34:41 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id 58EF28FC1A; Wed, 25 May 2011 19:34:39 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=EsGlCpMeIw85Gy1IHWHJoTo3ieATU4tNmYze/bSqBec= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=kWWxOIFCDSEA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=zXwiK2_UkJisIPLbFaQA:9 a=Wyg7-9KaIBhVjG6LOEUA:7 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 131463937; Wed, 25 May 2011 21:34:37 +0200 From: Hans Petter Selasky To: Jim Bryant Date: Wed, 25 May 2011 21:33:23 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4DDC20DF.6060805@gmail.com> <201105242324.15541.hselasky@c2i.net> <4DDD5245.3040500@gmail.com> In-Reply-To: <4DDD5245.3040500@gmail.com> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105252133.23321.hselasky@c2i.net> Cc: freebsd-drivers@freebsd.org, freebsd-usb@freebsd.org Subject: Re: traditional syscalls with DRIVER_MODULE ???? X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 19:34:41 -0000 Hi, On Wednesday 25 May 2011 21:02:29 Jim Bryant wrote: > do start_read/stop_read and start_write/stop_write map directly to the > userland read(2) and write(2) calls? No, but they are called from these calls. The idea is that you use the FIFO mechanism already present there when moving data, and poll() will be automatically handled. Probably that is not suitable for your purpose? > i had looked at this previously, and am a bit confused on if the above > is correct. > > even if they are the direct interface to read(2)/write(2), the issue of > a poll method for select(2) still exists... > > grepping all DRIVER_MODULE usages comes up with only two poll methods: > > powerpc/powermac/pmu.c: DEVMETHOD(adb_hb_controller_poll, > pmu_poll), > powerpc/powermac/cuda.c: DEVMETHOD(adb_hb_controller_poll, > cuda_poll), > > and those are unhelpful. > > please excuse me if these are newbie questions, but, i'm still in the > learning process. It is OK to ask questions :-) > > i can do this if there is a way to prevent DRIVER_MODULE from creating > the devfs nodes, and instead do this in a hybrid way using DRIVER_MODULE > and make_dev(9), which has the exact traditional functionality i want in > this. any ideas? Why can't you create the node when you receive a device_attach event? > two of the three device nodes this driver will create > will require read(2)/select(2) interfaces visible to userland, and the > third driver will require write(2) visible to userland. > the question is: is there a way to use DRIVER_MODULE, which seems > necessary for usbdi, yet create the devfs nodes using make_dev/cdevsw? > i would prefer to not have DRIVER_MODULE create the device nodes. DRIVER_MODULE() only will create devices if you have a load function which does so. It is only called once! --HPS