From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 21:29:37 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98E4D16A4CE for ; Sun, 25 Jan 2004 21:29:37 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4485643D3F for ; Sun, 25 Jan 2004 21:29:36 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 21048 invoked from network); 26 Jan 2004 05:29:34 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 26 Jan 2004 05:29:34 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 25 Jan 2004 23:29:33 -0600 (CST) From: Mike Silbersack To: arch@freebsd.org Message-ID: <20040125230314.S730@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Updating callout_reset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 05:29:37 -0000 Based on the work I've been doing with the rtc driver and some issues in the tcp stack with high hz values, I'd like to propose a change in the callout_reset interface. Currently, the timeout value is specified in ticks. This creates two problems: #1 - At high hz rates, the maximum timeout possible is reduced; we have at least one example of this causing problems in the kernel at present (16-bit sbtimeout values getting reduced from 327 to 32 seconds), there could be others we haven't caught. Many of these are likely to result from integer math errors introduced by authors who hadn't considered larger hz values occuring. #2 - Using ticks reduces the potential accuracy of wakeups with our default hz setting. For example, if one wishes to sleep for 5ms when hz=100, the only choices is to request one tick, or 10ms. However, if 5ms could be specified, the callout subsystem would be able to schedule more precise wakeups in places where the next timer interval was between 5 and 10ms away. Case #1 also provides a second justification for a change; any piece of code which requests a timeout must be aware of the system hz; moving to a standard time format would create more straightforward code. In order to ensure that modules and the like do not break, I would like to propose that we leave callout_reset defined as is and create a new function, callout_set (or some other clever name) which takes a struct *timespec in place of ticks. Optimizations as suggested in example #2 above would not be implemented right away, but would be possible due to the better interface. Thoughts? Mike "Silby" Silbersack From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 22:34:30 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 014F916A4CE for ; Sun, 25 Jan 2004 22:34:30 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 854FD43D46 for ; Sun, 25 Jan 2004 22:34:28 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0Q6YRuO062081; Mon, 26 Jan 2004 07:34:27 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Mike Silbersack From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 25 Jan 2004 23:29:33 CST." <20040125230314.S730@odysseus.silby.com> Date: Mon, 26 Jan 2004 07:34:27 +0100 Message-ID: <62080.1075098867@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: Updating callout_reset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 06:34:30 -0000 In message <20040125230314.S730@odysseus.silby.com>, Mike Silbersack writes: >In order to ensure that modules and the like do not break, I would like to >propose that we leave callout_reset defined as is and create a new >function, callout_set (or some other clever name) which takes a struct >*timespec in place of ticks. No, not timespec. Timespecs are stupid, slow, clumsy and unhandy and cumbersome. With a timespec you either need an MPunsafe hack function like libevents evConsTime() or a local stack variable. Make it a 64bit count of nanoseconds instead that way it can be used as a literal constant. It's OK with me if we want to have a function to contain the "* 1000000000LL" factor for us, and maybe even convenience functions for milli and microseconds. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 23:42:47 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC1B616A4CE for ; Sun, 25 Jan 2004 23:42:47 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 709C143D1D for ; Sun, 25 Jan 2004 23:42:46 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 45331 invoked from network); 26 Jan 2004 07:42:45 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 26 Jan 2004 07:42:45 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 26 Jan 2004 01:42:44 -0600 (CST) From: Mike Silbersack To: Poul-Henning Kamp In-Reply-To: <62080.1075098867@critter.freebsd.dk> Message-ID: <20040126013147.A1599@odysseus.silby.com> References: <62080.1075098867@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: Updating callout_reset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 07:42:47 -0000 On Mon, 26 Jan 2004, Poul-Henning Kamp wrote: > No, not timespec. > > Timespecs are stupid, slow, clumsy and unhandy and cumbersome. > > With a timespec you either need an MPunsafe hack function like > libevents evConsTime() or a local stack variable. > > Make it a 64bit count of nanoseconds instead that way it can be > used as a literal constant. > > It's OK with me if we want to have a function to contain the "* > 1000000000LL" factor for us, and maybe even convenience functions > for milli and microseconds. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 Ah, that would work better. I guess this getting ideas reviewed process does help. :) Do we have a preexisting name for the "64bit nanoseconds" type? Mike "Silby" Silbersack From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 23:50:34 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A46B16A4CE for ; Sun, 25 Jan 2004 23:50:34 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C49643D2D for ; Sun, 25 Jan 2004 23:50:32 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0Q7oTuO062673; Mon, 26 Jan 2004 08:50:30 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Mike Silbersack From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 26 Jan 2004 01:42:44 CST." <20040126013147.A1599@odysseus.silby.com> Date: Mon, 26 Jan 2004 08:50:29 +0100 Message-ID: <62672.1075103429@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: Updating callout_reset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 07:50:34 -0000 In message <20040126013147.A1599@odysseus.silby.com>, Mike Silbersack writes: >> Make it a 64bit count of nanoseconds instead that way it can be >> used as a literal constant. >> >> It's OK with me if we want to have a function to contain the "* >> 1000000000LL" factor for us, and maybe even convenience functions >> for milli and microseconds. >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > >Ah, that would work better. I guess this getting ideas reviewed process >does help. :) > >Do we have a preexisting name for the "64bit nanoseconds" type? No, and I don't think we need one for this. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 00:59:15 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57BAB16A4CE for ; Mon, 26 Jan 2004 00:59:15 -0800 (PST) Received: from dswu83.btconnect.com (dswu83.btconnect.com [193.113.154.14]) by mx1.FreeBSD.org (Postfix) with SMTP id D24A043D49 for ; Mon, 26 Jan 2004 00:59:11 -0800 (PST) (envelope-from BPICKLES@btconnect.com) Received: from sdlbase (actually host 148.209.134.81.in-addr.arpa) by dswu83 with SMTP-CUST (XT-PP) with ESMTP; Mon, 26 Jan 2004 08:58:56 +0000 Message-ID: <00c301c3e3eb$944845d0$1d02a8c0@sdlbase> From: "Bob Pickles" To: Date: Mon, 26 Jan 2004 09:05:43 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Device Driver Problem, Embedded Development X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bob Pickles List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 08:59:15 -0000 Hi all Been working with FreeBSD for a few weeks and found out that some of the kernel documentation is not available within 5.1. I have installed = everything! I have been trying to find the following functions: pci_mem_find() Need explanation of parameters. Managed to = work out the=20 other pci_ functions... bus_space_map() Need explanation of parameters to allow device = memory map. This is all that I need to get the driver working with the user app. Your thoughts are appreciated. Best Regards Bob Pickles From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 03:05:42 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 020BC16A4CE for ; Mon, 26 Jan 2004 03:05:42 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 155D843D1D for ; Mon, 26 Jan 2004 03:05:40 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i0QB5cLE008575; Mon, 26 Jan 2004 22:05:38 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i0QB5aEf014072; Mon, 26 Jan 2004 22:05:37 +1100 Date: Mon, 26 Jan 2004 22:05:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Mike Silbersack In-Reply-To: <20040125230314.S730@odysseus.silby.com> Message-ID: <20040126212725.E1244@gamplex.bde.org> References: <20040125230314.S730@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: Updating callout_reset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 11:05:42 -0000 On Sun, 25 Jan 2004, Mike Silbersack wrote: > #1 - At high hz rates, the maximum timeout possible is reduced; we have > at least one example of this causing problems in the kernel at present > (16-bit sbtimeout values getting reduced from 327 to 32 seconds), there > could be others we haven't caught. Many of these are likely to result > from integer math errors introduced by authors who hadn't considered > larger hz values occuring. Changing the interface wouldn't fix this, but would introduce new overflow possibilities (when the caller passes a timeout that cannot be represented as in "int" tick count). > #2 - Using ticks reduces the potential accuracy of wakeups with our > default hz setting. For example, if one wishes to sleep for 5ms when > hz=100, the only choices is to request one tick, or 10ms. However, if 5ms > could be specified, the callout subsystem would be able to schedule more > precise wakeups in places where the next timer interval was between 5 and > 10ms away. Converting from another format to a tick count in callout_reset() would be a good pessimization. Fine tuning the timeout would be a better pessimization. callout_reset() is designed to be very efficient, partly by not looking at its timeout arg. The code to decide how near the next tick is would have to make at least an expensive binuptime() call. > Case #1 also provides a second justification for a change; any piece of > code which requests a timeout must be aware of the system hz; moving to a > standard time format would create more straightforward code. This is a negative justification. Unless you reimplement callouts and make them slower, callers must be aware of their limits to use them efficiently and avoid representation problems. Many callers don't worry much about efficiency and do calculations like (hz / 10) to get the timeout. This is still more efficient than the 64-bit divisions and other complications needed to handle general conversions of times to timeouts. (Look at tvtohz(). Note that the complications in it have very little to do with struct timeval not being a scalar type. They are to handle representation problems.) Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 07:48:10 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D004416A4CE for ; Mon, 26 Jan 2004 07:48:10 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86FA043DAA for ; Mon, 26 Jan 2004 07:47:34 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0QFj3ET078327; Mon, 26 Jan 2004 08:45:04 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 26 Jan 2004 08:44:26 -0700 (MST) Message-Id: <20040126.084426.107520432.imp@bsdimp.com> To: bpickles@sbs.com, BPICKLES@btconnect.com From: "M. Warner Losh" In-Reply-To: <00c301c3e3eb$944845d0$1d02a8c0@sdlbase> References: <00c301c3e3eb$944845d0$1d02a8c0@sdlbase> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: Device Driver Problem, Embedded Development X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 15:48:10 -0000 In message: <00c301c3e3eb$944845d0$1d02a8c0@sdlbase> "Bob Pickles" writes: : I have been trying to find the following functions: : : pci_mem_find() Need explanation of parameters. Managed to work out the : other pci_ functions... This isn't a public function. Don't use it. In fact, I can't even find it in the current sources. I believe it was the old-style way to map memory. : bus_space_map() Need explanation of parameters to allow device memory map. Chances are excellent you don't want to use this one either. : This is all that I need to get the driver working with the user app. bus_alloc_resource() is what I think you want to use. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 14:04:09 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C583816A4CE for ; Mon, 26 Jan 2004 14:04:09 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 4029E43D49 for ; Mon, 26 Jan 2004 14:04:09 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 29689 invoked by uid 1000); 26 Jan 2004 22:04:10 -0000 Date: Mon, 26 Jan 2004 14:04:10 -0800 (PST) From: Nate Lawson To: arch@freebsd.org Message-ID: <20040126140100.T29680@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 22:04:09 -0000 I have a driver that knows the IO port it wants. It's not set up by a parent bus, so I can't use bus_set_resource(). This call returns NULL. Any idea how to debug why newbus is rejecting this request? The io port is not in use and the rid is unique. bus_alloc_resource(dev, SYS_RES_IOPORT, rid, 0x101c, 0x101c, 1, RF_ACTIVE); Thanks, -Nate From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 14:17:33 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E88D916A4CE for ; Mon, 26 Jan 2004 14:17:33 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1A1D43D1F for ; Mon, 26 Jan 2004 14:17:32 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0QMHWET082623; Mon, 26 Jan 2004 15:17:32 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 26 Jan 2004 15:17:28 -0700 (MST) Message-Id: <20040126.151728.133912536.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040126140100.T29680@root.org> References: <20040126140100.T29680@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 22:17:34 -0000 In message: <20040126140100.T29680@root.org> Nate Lawson writes: : I have a driver that knows the IO port it wants. It's not set up by a : parent bus, so I can't use bus_set_resource(). This call returns NULL. : Any idea how to debug why newbus is rejecting this request? The io port : is not in use and the rid is unique. : : bus_alloc_resource(dev, SYS_RES_IOPORT, rid, 0x101c, 0x101c, 1, : RF_ACTIVE); Ummm, you can use bus_set_resource() in the driver to do this (I've done it before). bus_set_resource() should return 0 to indicate success. bus_alloc_resource should then succeed. There may be one other step to do as well to make this work, but I'm not sure if it is an internal convention or actually required. The pci bus code does a resource_list_add for each of the resources the child uses, but I think that's an internal thing to the pci bus (that other busses do also). Warner From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 18:34:49 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71BF416A4BF for ; Wed, 1 Oct 2003 18:34:49 -0700 (PDT) Received: from smtp.noos.fr (nan-smtp-12.noos.net [212.198.2.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id D280D43FDD for ; Wed, 1 Oct 2003 18:34:46 -0700 (PDT) (envelope-from root@noos.fr) Received: (qmail 5739607 invoked by uid 0); 2 Oct 2003 01:34:42 -0000 Received: (qmail 71839524 invoked by uid 0); 28 Sep 2003 21:23:04 -0000 Received: from unknown (HELO mx2.freebsd.org) ([216.136.204.119]) (envelope-sender ) by 212.198.2.76 (qmail-ldap-1.03) with SMTP for ; 28 Sep 2003 21:23:04 -0000 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 85B405890A; Sun, 28 Sep 2003 14:22:26 -0700 (PDT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E587716A4FC; Sun, 28 Sep 2003 14:22:20 -0700 (PDT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E812216A4B3; Sun, 28 Sep 2003 14:22:11 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AB9744011; Sun, 28 Sep 2003 14:22:10 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h8SLM7LG000654; Sun, 28 Sep 2003 23:22:08 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org, current@freebsd.org From: Poul-Henning Kamp Message-ID: <653.1064784127@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org Subject: HEADSUP: Change of makedev() semantics. X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 02 Oct 2003 01:34:49 -0000 X-Original-Date: Sun, 28 Sep 2003 23:22:07 +0200 X-List-Received-Date: Thu, 02 Oct 2003 01:34:49 -0000 I am in the process of adding ref-counting and locking to dev_t, and would very much prefer if we could get this step completed soon before 5-STABLE gets branched. All this will be transparent to the majority of device drivers, as the refcounting will happen in the make_dev() and destroy_dev() family of calls and normal drivers need not know more about it. But there are a few remaining users of makedev() which get in the way of this effort, and we must get these fixed. Basically: 1. Do not call makedev(). 2. If you do cloning, please look at the patches I posted for if_tun/if_tap for how to do it. 3. If you do a "normal" device driver, cache the result from when you call make_dev(). 4. If you translate "foreign dev_t's", ie emulators or compat code, contact me. I'm not sure I understand how this works and should work and we need to talk. 5. If anything else or in doubt, ask me. Can I see some volounteers and/or maintainers please ? ./alpha/osf1/osf1_misc.c badly named local macro ? ./compat/linux/linux_stats.c ./compat/svr4/svr4_types.h compat code, not sure that this is correct now. Must be supported by new "finddev" semantics. ./dev/ata/atapi-cd.c cloning related to root mount. gets fixed when phk GEOMify the driver. ./dev/sound/midi/midi.h Not sure. ./dev/nmdm/nmdm.c pseudo-cloning. Should do real cloning. ./dev/syscons/syscons.c Related to console initialization. Maybe tricky. ./dev/sound/pcm/dsp.c ./dev/sound/pcm/mixer.c ./dev/usb/ugen.c ./dev/usb/uscanner.c Failure to cache result of make_dev() ./dev/vinum Failure to cache result of make_dev() ? Thanks in advance! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"