From owner-freebsd-usb@FreeBSD.ORG Thu May 26 21:28:42 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 D66F2106564A; Thu, 26 May 2011 21:28:42 +0000 (UTC) (envelope-from kc5vdj.freebsd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 430608FC16; Thu, 26 May 2011 21:28:41 +0000 (UTC) Received: by gwb15 with SMTP id 15so612796gwb.13 for ; Thu, 26 May 2011 14:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sMXIGAQYRZcqj6EJbh+QDc3mUdIlZlOW/hxvI222B68=; b=MWcfm5XbcCbfs01g4DjRDN5nJf9Tp1Y45h0PNfjCk5Ceco2CwI9kBbjOFMOiklyemw kuUGRpl2A23aHFr+/VT/Hi7D3mkHrN0l2sOTpXEwIa6Dp+686hiYaYZgw2/zD7CPWFEG M51lkA86DxlnC8gZiwWdxQJrbC9lbqsd9RBTA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=JYP/TLktpP7eTBavGy8IyKgiLmSQPfX81UnQhiKoDnRncfqgeCOyYuc5Wt6bjKK+dZ eVAqxGxy0GkhnzXO+qGKa9lzKIq12BGJifwiaIfBM7KuH17yiKOerFI/f8NDI3LK0ORV P0trcT9jlC1wupphWUv8w9QTH6bO3kUQl6/JM= Received: by 10.146.248.19 with SMTP id v19mr1336053yah.25.1306445321351; Thu, 26 May 2011 14:28:41 -0700 (PDT) Received: from argus.electron-tube.net (desm-44-169.dsl.netins.net [167.142.44.169]) by mx.google.com with ESMTPS id b25sm955071anb.46.2011.05.26.14.28.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2011 14:28:40 -0700 (PDT) Message-ID: <4DDD7ED9.90500@gmail.com> Date: Wed, 25 May 2011 17:12:41 -0500 From: Jim Bryant User-Agent: Thunderbird 2.0.0.24 (X11/20100911) MIME-Version: 1.0 To: Hans Petter Selasky References: <4DDC20DF.6060805@gmail.com> <201105242324.15541.hselasky@c2i.net> <4DDD5245.3040500@gmail.com> <201105252133.23321.hselasky@c2i.net> In-Reply-To: <201105252133.23321.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 26 May 2011 21:28:43 -0000 excuse me while i pull my head out of my posterior... yup. it wasn't DRIVER_MODULE() doing it... it was the usb_fifo_attach.... i think i'm back on the right track now... thanks for pointing me in the right direction. Hans Petter Selasky wrote: > 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 > >