From owner-freebsd-arch Sun Aug 12 7:40:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp4.ihug.co.nz (smtp4.ihug.co.nz [203.109.252.5]) by hub.freebsd.org (Postfix) with ESMTP id C66B337B405 for ; Sun, 12 Aug 2001 07:40:44 -0700 (PDT) (envelope-from e_URL@ihug.co.nz) Received: from smtp.ihug.co.nz (203-173-247-12.nzwide.ihug.co.nz [203.173.247.12]) by smtp4.ihug.co.nz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id CAA25194 for ; Mon, 13 Aug 2001 02:40:12 +1200 X-Authentication-Warning: smtp4.ihug.co.nz: Host 203-173-247-12.nzwide.ihug.co.nz [203.173.247.12] claimed to be smtp.ihug.co.nz Message-Id: <997626882.240@ihug.co.nz> Date: Mon, 13 Aug 2001 02:34:42 -1200 To: freebsd-arch@freebsd.org From: e_URL@ihug.co.nz (DoS Research) Subject: Denial of Service Research MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dear Sir/Madam Our names are Leon Shu and John Zheng. We are students at the UNITEC Institute of Technology (New Zealand), and currently working on a DoS/DDoS (Denial of service) research project, as required for our degree. For this project we conduct research on the analysis of the DoS/DDoS technologies and threats, as well as anti DoS/DDoS tools. As part of this research, we found your email on your web site. You could be of great help to us if you could fill out our on-line survey, which we have prepared for this project. In return, we will email you the summarised outcome of the project if you do provide your email address in the survey form. Please find the survey here: http://hyperdisc.unitec.ac.nz/dos_research/ the information you give us will be analysed and results will be presented in an anonymous, generic form. Please let us assure you that all your information will remain strictly confidential. Thank you very much for assisting us! if you need to contact us, please email to e_URL@hotmail.com Yours faithfully Leon & John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 3:40:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 729) id 55AE437B406; Mon, 13 Aug 2001 03:40:30 -0700 (PDT) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0 To: "Andrey A. Chernov" Cc: arch@freebsd.org Subject: Re: CFR: fseek<0 + feof error (with fix) In-Reply-To: Your message of "Fri, 10 Aug 2001 23:29:40 +0400." <20010810232939.A14964@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain Message-Id: <20010813104030.55AE437B406@hub.freebsd.org> Date: Mon, 13 Aug 2001 03:40:30 -0700 (PDT) From: jkoshy@FreeBSD.ORG (Joseph Koshy) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > According to POSIX fseek{o}() description, it must return > > [EINVAL] > The whence argument is invalid. The resulting file-position > indicator would be set to a negative value. > > which expicetly disallows seek beyond beginning of a file. Currently we FreeBSD's implementation of `lseek()' allows negative offsets --- these seem to be required to allow reading of /dev/[k]mem. See PR kern/6184. Regards, Koshy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 4: 0: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 97BDB37B40B; Mon, 13 Aug 2001 04:00:05 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.4/8.11.4) id f7DB02h75324; Mon, 13 Aug 2001 15:00:03 +0400 (MSD) (envelope-from ache) Date: Mon, 13 Aug 2001 14:59:59 +0400 From: "Andrey A. Chernov" To: Joseph Koshy Cc: arch@FreeBSD.ORG Subject: Re: CFR: fseek<0 + feof error (with fix) Message-ID: <20010813145956.A75227@nagual.pp.ru> References: <20010810232939.A14964@nagual.pp.ru> <20010813104030.55AE437B406@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010813104030.55AE437B406@hub.freebsd.org> User-Agent: Mutt/1.3.20i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Aug 13, 2001 at 03:40:30 -0700, Joseph Koshy wrote: > > > > According to POSIX fseek{o}() description, it must return > > > > [EINVAL] > > The whence argument is invalid. The resulting file-position > > indicator would be set to a negative value. > > > > which expicetly disallows seek beyond beginning of a file. Currently we > > FreeBSD's implementation of `lseek()' allows negative offsets --- these > seem to be required to allow reading of /dev/[k]mem. See PR kern/6184. We talk here about _fseek_, not about _lseek_. For lseek POSIX word are different: [EINVAL] The whence argument is not a proper value, or the resulting file offset would be negative for a regular file, block special file, or directory. I.e. no negative offset allowed for fseek at all while it allowed for lseek expecting regular, block special or directory file. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 4:28:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 729) id ABF4437B406; Mon, 13 Aug 2001 04:28:48 -0700 (PDT) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0 To: "Andrey A. Chernov" Cc: arch@freebsd.org Subject: Re: CFR: fseek<0 + feof error (with fix) In-Reply-To: Your message of "Mon, 13 Aug 2001 14:59:59 +0400." <20010813145956.A75227@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain Message-Id: <20010813112848.ABF4437B406@hub.freebsd.org> Date: Mon, 13 Aug 2001 04:28:48 -0700 (PDT) From: jkoshy@FreeBSD.ORG (Joseph Koshy) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG jk> FreeBSD's implementation of `lseek()' allows negative offsets --- these jk> seem to be required to allow reading of /dev/[k]mem. See PR kern/6184. ac> We talk here about _fseek_, not about _lseek_. For lseek POSIX word are ac> different: ac> [EINVAL] The whence argument is not a proper value, or the resulting file ac> offset would be negative for a regular file, block special file, or ac> directory. ac> I.e. no negative offset allowed for fseek at all while it allowed for ac> lseek expecting regular, block special or directory file. I think I didn't explain my point clearly: `fseek(3)' ultimately invokes `lseek(2)'. From my reading of the code in "libc/stdio/fseek.c", we don't handle character device files specially and just pass the arguments through to `lseek()'. So, if you are planning to disallow negative offsets to `fseek()', you will need to special-case character special files to allow negative offsets there. Allowing negative file offsets for character special files is not actually prohibited by the standards, IIRC, since this behaviour is termed 'implementation dependent'. Perhaps someone with more standards expertise than I have could clarify. Koshy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 5:55:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 7CB4337B40B; Mon, 13 Aug 2001 05:55:20 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.4/8.11.4) id f7DCtIA76656; Mon, 13 Aug 2001 16:55:19 +0400 (MSD) (envelope-from ache) Date: Mon, 13 Aug 2001 16:55:17 +0400 From: "Andrey A. Chernov" To: Joseph Koshy Cc: arch@FreeBSD.ORG Subject: Re: CFR: fseek<0 + feof error (with fix) Message-ID: <20010813165517.A76432@nagual.pp.ru> References: <20010813145956.A75227@nagual.pp.ru> <20010813112848.ABF4437B406@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010813112848.ABF4437B406@hub.freebsd.org> User-Agent: Mutt/1.3.20i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Aug 13, 2001 at 04:28:48 -0700, Joseph Koshy wrote: > > I think I didn't explain my point clearly: `fseek(3)' ultimately invokes > `lseek(2)'. From my reading of the code in "libc/stdio/fseek.c", we don't We must stop fseek() far before lseek(2) call because of its bad effect on ungetc() and feof(). Fixing lseek() per POSIX is out of my scope at this moment. > handle character device files specially and just pass the arguments through > to `lseek()'. Yes, there is a problem, we can't stop fseek() in 100% cases, in complex cases only for files with fstat() possible. > So, if you are planning to disallow negative offsets to > `fseek()', you will need to special-case character special files to allow > negative offsets there. We don't need. No negative offsets allowed for fseek(), in all cases, read my POSIX quote. Remember fseek() is not lseek(), POSIX treat them differently. fseek() is stdio and have some documented side effects which turns to nightmare with negative seeks, thats why POSIX disallow negative ofsets for fseek() completely (but not for lseek()). > Allowing negative file offsets for character special files is not actually > prohibited by the standards, IIRC, since this behaviour is termed > 'implementation dependent'. Perhaps someone with more standards expertise > than I have could clarify. Yes, but for lseek() only, not for fseek(). -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 6:13:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 3A10937B40F; Mon, 13 Aug 2001 06:13:24 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.4/8.11.4) id f7DDDLR76937; Mon, 13 Aug 2001 17:13:22 +0400 (MSD) (envelope-from ache) Date: Mon, 13 Aug 2001 17:13:17 +0400 From: "Andrey A. Chernov" To: Joseph Koshy Cc: arch@FreeBSD.ORG Subject: Re: CFR: fseek<0 + feof error (with fix) Message-ID: <20010813171314.A76817@nagual.pp.ru> References: <20010813145956.A75227@nagual.pp.ru> <20010813112848.ABF4437B406@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010813112848.ABF4437B406@hub.freebsd.org> User-Agent: Mutt/1.3.20i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Aug 13, 2001 at 04:28:48 -0700, Joseph Koshy wrote: > > Allowing negative file offsets for character special files is not actually > prohibited by the standards, IIRC, since this behaviour is termed > 'implementation dependent'. Perhaps someone with more standards expertise > than I have could clarify. Yet once, to make the difference more visible. What POSIX says about lseek(): [EINVAL] The whence argument is not a proper value, or the resulting file offset would be negative for a regular file, block special file, or directory. And now what about fseek{o}(): [EINVAL] The whence argument is invalid. The resulting file-position indicator would be set to a negative value. i.e. for all cases. BTW, for example I have OS/2 gcc result for test program I post and fseek() is POSIXed there, not so broken as ours. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 6:58:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 7B10D37B418; Mon, 13 Aug 2001 06:58:00 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f7DDvss76617; Mon, 13 Aug 2001 16:57:54 +0300 (EEST) (envelope-from ru) Date: Mon, 13 Aug 2001 16:57:54 +0300 From: Ruslan Ermilov To: Bruce Evans , "David O'Brien" Cc: arch@FreeBSD.org Subject: __RCSID() and __VERSION() macros and their ``static const char'' equivalents Message-ID: <20010813165753.A74504@sunbay.com> Mail-Followup-To: Bruce Evans , David O'Brien , arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce, David! What is the reason why we should use the old style VCS ID declarations like this: static const char rcsid[] = "$FreeBSD$"; instead of their modern equivalent, __RCSID() macro? Not only the macro is backwards compatible in the non-gcc or non-ELF case, but it also "produces" more compact objects. Similarly for copyright[] versus __COPYRIGHT(). (This is documented in the style(9) policy document.) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 7:39:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from columbus.cris.net (ns.cris.net [212.110.128.65]) by hub.freebsd.org (Postfix) with ESMTP id DF92C37B403; Mon, 13 Aug 2001 07:39:22 -0700 (PDT) (envelope-from ml@phantom.cris.net) Received: from phantom.cris.net (phantom.cris.net [212.110.130.74]) by columbus.cris.net (8.9.3/8.9.3) with ESMTP id RAA29841; Mon, 13 Aug 2001 17:39:20 +0300 (EEST) Received: (from ml@localhost) by phantom.cris.net (8.11.1/8.11.1) id f7DEfEX26493; Mon, 13 Aug 2001 17:41:14 +0300 (EEST) (envelope-from ml) Date: Mon, 13 Aug 2001 17:41:14 +0300 From: Alexey Zelkin To: Ruslan Ermilov Cc: Bruce Evans , "David O'Brien" , arch@FreeBSD.ORG Subject: Re: __RCSID() and __VERSION() macros and their ``static const char'' equivalents Message-ID: <20010813174114.A26468@phantom.cris.net> References: <20010813165753.A74504@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010813165753.A74504@sunbay.com>; from ru@FreeBSD.ORG on Mon, Aug 13, 2001 at 04:57:54PM +0300 X-Operating-System: FreeBSD 4.2-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hi, I raised almost same questions two months ago. We even came to conclusion, but David asked to suspend this task until he'll make some kinds of this black magic in FreeBSD src tree (to avoid merge conflicts). But I still not hear anything back. On Mon, Aug 13, 2001 at 04:57:54PM +0300, Ruslan Ermilov wrote: > Bruce, David! > > What is the reason why we should use the old style VCS ID declarations > like this: > > static const char rcsid[] = > "$FreeBSD$"; > > instead of their modern equivalent, __RCSID() macro? > > Not only the macro is backwards compatible in the non-gcc or non-ELF > case, but it also "produces" more compact objects. > > Similarly for copyright[] versus __COPYRIGHT(). > > (This is documented in the style(9) policy document.) > > > Cheers, > -- > Ruslan Ermilov Oracle Developer/DBA, > ru@sunbay.com Sunbay Software AG, > ru@FreeBSD.org FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 8:52:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from albert.ies.net (albert.ies.net [208.193.197.6]) by hub.freebsd.org (Postfix) with ESMTP id D4CC837B411 for ; Mon, 13 Aug 2001 08:52:51 -0700 (PDT) (envelope-from dmontal@polibrid.com) Received: from DM ([208.241.30.123]) by albert.ies.net (Post.Office MTA v3.5.3 release 223 ID# 0-50103U5000L500S0V35) with SMTP id net for ; Mon, 13 Aug 2001 10:48:44 -0700 Reply-To: From: dmontal@polibrid.com (Diego Montalvo) To: Subject: FreeBSD to go? Date: Mon, 13 Aug 2001 10:42:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, What are the proper steps in organizing a FreeBSD development team. I would like to begin development of a FreeBSD for mobile platforms, example: PocketPC, Mobile phones, Palm Devices, etc.... The link below: is linux on a portable device. http://waba.sourceforge.net/html/screenshots/iPAQ.html Diego To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 8:56:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from web13408.mail.yahoo.com (web13408.mail.yahoo.com [216.136.175.66]) by hub.freebsd.org (Postfix) with SMTP id 70AF337B409 for ; Mon, 13 Aug 2001 08:56:40 -0700 (PDT) (envelope-from dmontal2@yahoo.com) Message-ID: <20010813155640.72758.qmail@web13408.mail.yahoo.com> Received: from [208.241.30.123] by web13408.mail.yahoo.com; Mon, 13 Aug 2001 08:56:40 PDT Date: Mon, 13 Aug 2001 08:56:40 -0700 (PDT) From: Diego Montalvo Subject: FreeBSD to go? To: freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, What are the proper steps in organizing a FreeBSD development team. I would like to begin development of a FreeBSD for mobile platforms, example: PocketPC, Mobile phones, Palm Devices, etc.... The link below: is linux on a portable device. http://waba.sourceforge.net/html/screenshots/iPAQ.html Diego __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 9:45:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (dsl092-013-169.sfo1.dsl.speakeasy.net [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id A8E3037B401; Mon, 13 Aug 2001 09:45:49 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f7DGjnM94977; Mon, 13 Aug 2001 09:45:49 -0700 (PDT) (envelope-from obrien) Date: Mon, 13 Aug 2001 09:45:49 -0700 From: "David O'Brien" To: Alexey Zelkin Cc: Ruslan Ermilov , Bruce Evans , arch@FreeBSD.ORG Subject: Re: __RCSID() and __VERSION() macros and their ``static const char'' equivalents Message-ID: <20010813094549.A94831@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010813165753.A74504@sunbay.com> <20010813174114.A26468@phantom.cris.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010813174114.A26468@phantom.cris.net>; from phantom@FreeBSD.ORG on Mon, Aug 13, 2001 at 05:41:14PM +0300 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Aug 13, 2001 at 05:41:14PM +0300, Alexey Zelkin wrote: > I raised almost same questions two months ago. We even came to > conclusion, but David asked to suspend this task until he'll make > some kinds of this black magic in FreeBSD src tree (to avoid merge > conflicts). But I still not hear anything back. Acutally I am waiting to hear back from you and BDE about the proposals I made in June (last message I sent on the topic was 21-June-2001). > > What is the reason why we should use the old style VCS ID declarations > > like this: > > > > static const char rcsid[] = > > "$FreeBSD$"; > > > > instead of their modern equivalent, __RCSID() macro? __RCSID() should be forgotten about. It is a lost cause like using "$Id$". There is just too much imported and barrowed code that uses __RCSID for us to try to use it also (I tried). I have a few ideas on the topic and let see if the small group of us discussing the issue can flush something out. > > Not only the macro is backwards compatible in the non-gcc or non-ELF > > case, but it also "produces" more compact objects. How is it going to produce more compat objects [all the time for GCC and non-GCC compilers]. I believe you mean in some implimentations. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 9:58:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 599FA37B407; Mon, 13 Aug 2001 09:58:32 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f7DGwQk00183; Mon, 13 Aug 2001 19:58:26 +0300 (EEST) (envelope-from ru) Date: Mon, 13 Aug 2001 19:58:26 +0300 From: Ruslan Ermilov To: "David O'Brien" Cc: Alexey Zelkin , Bruce Evans , arch@FreeBSD.ORG Subject: Re: __RCSID() and __VERSION() macros and their ``static const char'' equivalents Message-ID: <20010813195826.A99201@sunbay.com> Mail-Followup-To: David O'Brien , Alexey Zelkin , Bruce Evans , arch@FreeBSD.ORG References: <20010813165753.A74504@sunbay.com> <20010813174114.A26468@phantom.cris.net> <20010813094549.A94831@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010813094549.A94831@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Mon, Aug 13, 2001 at 09:45:49AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Aug 13, 2001 at 09:45:49AM -0700, David O'Brien wrote: > On Mon, Aug 13, 2001 at 05:41:14PM +0300, Alexey Zelkin wrote: > > I raised almost same questions two months ago. We even came to > > conclusion, but David asked to suspend this task until he'll make > > some kinds of this black magic in FreeBSD src tree (to avoid merge > > conflicts). But I still not hear anything back. > > Acutally I am waiting to hear back from you and BDE about the proposals I > made in June (last message I sent on the topic was 21-June-2001). > > > > > What is the reason why we should use the old style VCS ID declarations > > > like this: > > > > > > static const char rcsid[] = > > > "$FreeBSD$"; > > > > > > instead of their modern equivalent, __RCSID() macro? > > __RCSID() should be forgotten about. It is a lost cause like using > "$Id$". There is just too much imported and barrowed code that uses > __RCSID for us to try to use it also (I tried). I have a few ideas on > the topic and let see if the small group of us discussing the issue can > flush something out. > I can't see what's wrong with current implementation of __RCSID(), it definitely works. > > > Not only the macro is backwards compatible in the non-gcc or non-ELF > > > case, but it also "produces" more compact objects. > > How is it going to produce more compat objects [all the time for GCC and > non-GCC compilers]. I believe you mean in some implimentations. > Umm, there are two versions of lower level __IDSTRING(): #if defined(__GNUC__) && defined(__ELF__) #define __IDSTRING(name,string) __asm__(".ident\t\"" string "\"") #else #define __IDSTRING(name,string) static const char name[] __unused = string #endif And the version using ``.ident'' produces more compact objects. Just check it! Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 10: 3:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (dsl092-013-169.sfo1.dsl.speakeasy.net [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 8BA2C37B40E; Mon, 13 Aug 2001 10:03:29 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f7DH3TS99819; Mon, 13 Aug 2001 10:03:29 -0700 (PDT) (envelope-from obrien) Date: Mon, 13 Aug 2001 10:03:29 -0700 From: "David O'Brien" To: Alexey Zelkin , Bruce Evans , arch@FreeBSD.ORG Subject: Re: __RCSID() and __VERSION() macros and their ``static const char'' equivalents Message-ID: <20010813100329.C94831@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010813165753.A74504@sunbay.com> <20010813174114.A26468@phantom.cris.net> <20010813094549.A94831@dragon.nuxi.com> <20010813195826.A99201@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010813195826.A99201@sunbay.com>; from ru@FreeBSD.ORG on Mon, Aug 13, 2001 at 07:58:26PM +0300 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Aug 13, 2001 at 07:58:26PM +0300, Ruslan Ermilov wrote: > > > > __RCSID() should be forgotten about. It is a lost cause like using > > "$Id$". There is just too much imported and barrowed code that uses > > __RCSID for us to try to use it also (I tried). I have a few ideas on > > the topic and let see if the small group of us discussing the issue can > > flush something out. > > > I can't see what's wrong with current implementation of __RCSID(), > it definitely works. There are problems with it. Please don't turn this into a bikeshed. The small working group we've had on this is suffient to work out something. > And the version using ``.ident'' produces more compact objects. > Just check it! I *realize* that. Read what I said! You wrote a sweaping generalization. I simply said it was. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 10:17: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 7BA6737B401; Mon, 13 Aug 2001 10:16:56 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f7DHGqj03441; Mon, 13 Aug 2001 20:16:52 +0300 (EEST) (envelope-from ru) Date: Mon, 13 Aug 2001 20:16:52 +0300 From: Ruslan Ermilov To: "David O'Brien" Cc: Alexey Zelkin , Bruce Evans , arch@FreeBSD.ORG Subject: Re: __RCSID() and __VERSION() macros and their ``static const char'' equivalents Message-ID: <20010813201652.A2099@sunbay.com> Mail-Followup-To: David O'Brien , Alexey Zelkin , Bruce Evans , arch@FreeBSD.ORG References: <20010813165753.A74504@sunbay.com> <20010813174114.A26468@phantom.cris.net> <20010813094549.A94831@dragon.nuxi.com> <20010813195826.A99201@sunbay.com> <20010813100329.C94831@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010813100329.C94831@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Mon, Aug 13, 2001 at 10:03:29AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Aug 13, 2001 at 10:03:29AM -0700, David O'Brien wrote: > On Mon, Aug 13, 2001 at 07:58:26PM +0300, Ruslan Ermilov wrote: > > > > > > __RCSID() should be forgotten about. It is a lost cause like using > > > "$Id$". There is just too much imported and barrowed code that uses > > > __RCSID for us to try to use it also (I tried). I have a few ideas on > > > the topic and let see if the small group of us discussing the issue can > > > flush something out. > > > > > I can't see what's wrong with current implementation of __RCSID(), > > it definitely works. > > There are problems with it. Please don't turn this into a bikeshed. The > small working group we've had on this is suffient to work out something. > I don't understand. Under the "small group of us", do you refer to this thread, or to another one? If the former, I'm sorry, and am waiting for "ideas on the topic" from you. I have not (yet) heard them, that's why I asked. Am I not allowed to know your ideas/concerns? (You behave like if I already knew them, and am saying something stupid.) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 11:13:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (dsl092-013-169.sfo1.dsl.speakeasy.net [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 7993D37B406; Mon, 13 Aug 2001 11:13:27 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f7DIDRM16988; Mon, 13 Aug 2001 11:13:27 -0700 (PDT) (envelope-from obrien) Date: Mon, 13 Aug 2001 11:13:27 -0700 From: "David O'Brien" To: Alexey Zelkin , Bruce Evans , arch@FreeBSD.ORG Subject: Re: __RCSID() and __VERSION() macros and their ``static const char'' equivalents Message-ID: <20010813111327.A16196@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010813165753.A74504@sunbay.com> <20010813174114.A26468@phantom.cris.net> <20010813094549.A94831@dragon.nuxi.com> <20010813195826.A99201@sunbay.com> <20010813100329.C94831@dragon.nuxi.com> <20010813201652.A2099@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010813201652.A2099@sunbay.com>; from ru@FreeBSD.ORG on Mon, Aug 13, 2001 at 08:16:52PM +0300 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Aug 13, 2001 at 08:16:52PM +0300, Ruslan Ermilov wrote: > > There are problems with it. Please don't turn this into a bikeshed. The > > small working group we've had on this is suffient to work out something. > > > I don't understand. Under the "small group of us", do you refer to this > thread, or to another one? If the former, I'm sorry, and am waiting for > "ideas on the topic" from you. I have not (yet) heard them, that's why I > asked. Am I not allowed to know your ideas/concerns? (You behave like > if I already knew them, and am saying something stupid.) The group that has already been discussing this. It isn't a secret, but I'm not going to open it up to -arch right now and start a bikeshed. I don't have the energy for it today. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 13 21:54:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hotmail.com (f200.pav2.hotmail.com [64.4.37.200]) by hub.freebsd.org (Postfix) with ESMTP id 1178237B40E for ; Mon, 13 Aug 2001 21:54:14 -0700 (PDT) (envelope-from sumanth_vi@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 13 Aug 2001 21:54:13 -0700 Received: from 202.177.132.140 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 14 Aug 2001 04:54:13 GMT X-Originating-IP: [202.177.132.140] From: "sumanth vidyadhara" To: freebsd-arch@FreeBSD.org Subject: the call to resource_int_value how does it work Date: Tue, 14 Aug 2001 04:54:13 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Aug 2001 04:54:13.0984 (UTC) FILETIME=[2A27AE00:01C1247D] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I would like to know how does resource_int_value works because there in no man page for that in freebsd 4.3. I would like to use this call to read tunable paramters at run time in the network card driver, since if_fxp driver is already doing that with the latest source. Can someone tell me how it works and how to use the device hints to set those arguments in resource_int_value. The below code is na extract from if_fxp.c network driver The parameter prefer_iomap he says populate using hints. hint.fxp.0.prefer_iomap="1" How do we get the hints for this device. and is the tunable populated after kldload at the prompt or before kldload /* * Figure out which we should try first - memory mapping or i/o mapping? * We default to memory mapping. Then we accept an override from the * command line. Then we check to see which one is enabled. */ m1 = PCIM_CMD_MEMEN; m2 = PCIM_CMD_PORTEN; prefer_iomap = 0; if (resource_int_value(device_get_name(dev), device_get_unit(dev), "prefer_iomap", &prefer_iomap) == 0 && prefer_iomap != 0) { m1 = PCIM_CMD_PORTEN; m2 = PCIM_CMD_MEMEN; } The OS version of freebsd is 4.3. Any help is greatly appreciated. Regards, Sumanth _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 14 0:10:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 120F937B40A for ; Tue, 14 Aug 2001 00:10:12 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 113666ACBC; Tue, 14 Aug 2001 16:40:44 +0930 (CST) Date: Tue, 14 Aug 2001 16:40:44 +0930 From: Greg Lehey To: Diego Montalvo Cc: freebsd-arch@FreeBSD.org Subject: Re: FreeBSD to go? Message-ID: <20010814164044.M61413@wantadilla.lemis.com> References: <20010813155640.72758.qmail@web13408.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010813155640.72758.qmail@web13408.mail.yahoo.com>; from dmontal2@yahoo.com on Mon, Aug 13, 2001 at 08:56:40AM -0700 Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday, 13 August 2001 at 8:56:40 -0700, Diego Montalvo wrote: > Hello, > > What are the proper steps in organizing a FreeBSD > development team. I would like to begin development > of a FreeBSD for mobile platforms, example: PocketPC, > Mobile phones, Palm Devices, etc.... There's no formal procedure. If you want to do this, just fire away. Ask specific questions when you can't make up your own mind. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 15 1:53: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hermes.dialup.ru (hermes.dialup.ru [194.87.16.230]) by hub.freebsd.org (Postfix) with ESMTP id 2BE6D37B405; Wed, 15 Aug 2001 01:52:51 -0700 (PDT) (envelope-from ache@hermes.dialup.ru) Received: (from ache@localhost) by hermes.dialup.ru (8.11.5/8.11.5) id f7F8qm702600; Wed, 15 Aug 2001 12:52:48 +0400 (MSD) (envelope-from ache) Date: Wed, 15 Aug 2001 12:52:48 +0400 From: "Andrey A. Chernov" To: arch@freebsd.org, current@freebsd.org Subject: CFR: lseek() POSIXed patch Message-ID: <20010815125248.A2588@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Here it is what POSIX says about lseek(): [EINVAL] The whence argument is not a proper value, or the resulting file offset would be negative for a regular file, block special file, or directory. [EOVERFLOW] The resulting file offset would be a value which cannot be represented correctly in an object of type off_t. The patch below adds both cases, i.e. disallow negative seeks for VREG, VDIR, VBLK and add off_t overflow checks. I plan to commit this, please review. --- vfs_syscalls.c.old Wed Aug 15 04:45:30 2001 +++ vfs_syscalls.c Wed Aug 15 12:46:12 2001 @@ -1614,29 +1614,44 @@ register struct filedesc *fdp = p->p_fd; register struct file *fp; struct vattr vattr; - int error; + off_t offset; + int error, no_neg_seek; if ((u_int)SCARG(uap, fd) >= fdp->fd_nfiles || (fp = fdp->fd_ofiles[SCARG(uap, fd)]) == NULL) return (EBADF); if (fp->f_type != DTYPE_VNODE) return (ESPIPE); + error = VOP_GETATTR((struct vnode *)fp->f_data, &vattr, cred, p); + no_neg_seek = (!error && + (vattr.va_type == VREG || + vattr.va_type == VDIR || + vattr.va_type == VBLK)); + offset = SCARG(uap, offset); switch (SCARG(uap, whence)) { case L_INCR: - fp->f_offset += SCARG(uap, offset); + if ((fp->f_offset > 0 && offset > 0 && + offset + fp->f_offset < 0) || + (fp->f_offset < 0 && offset < 0 && + offset + fp->f_offset > 0)) + return (EOVERFLOW); + offset += fp->f_offset; break; case L_XTND: - error=VOP_GETATTR((struct vnode *)fp->f_data, &vattr, cred, p); if (error) return (error); - fp->f_offset = SCARG(uap, offset) + vattr.va_size; + if (offset > 0 && (off_t)(offset + vattr.va_size) < 0) + return (EOVERFLOW); + offset += vattr.va_size; break; case L_SET: - fp->f_offset = SCARG(uap, offset); break; default: return (EINVAL); } + if (no_neg_seek && offset < 0) + return (EINVAL); + fp->f_offset = offset; *(off_t *)(p->p_retval) = fp->f_offset; return (0); } -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 15 3:18:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 45D8637B407; Wed, 15 Aug 2001 03:18:11 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA27875; Wed, 15 Aug 2001 20:17:57 +1000 Date: Wed, 15 Aug 2001 20:15:21 +1000 (EST) From: Bruce Evans X-X-Sender: To: "Andrey A. Chernov" Cc: , Subject: Re: CFR: lseek() POSIXed patch In-Reply-To: <20010815125248.A2588@nagual.pp.ru> Message-ID: <20010815190108.J19482-100000@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 15 Aug 2001, Andrey A. Chernov wrote: > The patch below adds both cases, i.e. disallow negative seeks for VREG, > VDIR, VBLK and add off_t overflow checks. > > I plan to commit this, please review. > > --- vfs_syscalls.c.old Wed Aug 15 04:45:30 2001 > +++ vfs_syscalls.c Wed Aug 15 12:46:12 2001 > @@ -1614,29 +1614,44 @@ > register struct filedesc *fdp = p->p_fd; > register struct file *fp; > struct vattr vattr; > - int error; > + off_t offset; > + int error, no_neg_seek; > > if ((u_int)SCARG(uap, fd) >= fdp->fd_nfiles || > (fp = fdp->fd_ofiles[SCARG(uap, fd)]) == NULL) > return (EBADF); > if (fp->f_type != DTYPE_VNODE) > return (ESPIPE); > + error = VOP_GETATTR((struct vnode *)fp->f_data, &vattr, cred, p); > + no_neg_seek = (!error && > + (vattr.va_type == VREG || > + vattr.va_type == VDIR || > + vattr.va_type == VBLK)); The type is in vp->v_type (where vp = (struct vnode *)fp->f_data), so the VOP_GETTATTR() call can be avoided except in the L_XTND case, as in the old code. I think permitting negative offsets for the VCHR case only is enough. > + offset = SCARG(uap, offset); > switch (SCARG(uap, whence)) { > case L_INCR: > - fp->f_offset += SCARG(uap, offset); > + if ((fp->f_offset > 0 && offset > 0 && > + offset + fp->f_offset < 0) || > + (fp->f_offset < 0 && offset < 0 && > + offset + fp->f_offset > 0)) > + return (EOVERFLOW); You used a slightly simpler, slightly less ugly overflow checks in fseek.c. This seems to be a bug in fseek.c. Since the checks are so messy, maybe they should be messy enough to not depend on undefined behaviour (they check for overflow after overflow may have occurred). Something like: #define OFF_T_MAX 0x7FFFFFFFFFFFFFFF /* XXX */ #define OFF_T_MIN (-0x7FFFFFFFFFFFFFFF - 1) /* XXX */ start = fp->f_offset; if (offset > 0 && start > OFF_T_MAX - offset || offset < 0 && start < OFF_T_MIN - offset) return (EOVERFLOW); > + if ((fp->f_offset > 0 && offset > 0 && > + offset + fp->f_offset < 0) || > + (fp->f_offset < 0 && offset < 0 && > + offset + fp->f_offset > 0)) > + offset += fp->f_offset; > break; > case L_XTND: > - error=VOP_GETATTR((struct vnode *)fp->f_data, &vattr, cred, p); > if (error) > return (error); > - fp->f_offset = SCARG(uap, offset) + vattr.va_size; > + if (offset > 0 && (off_t)(offset + vattr.va_size) < 0) > + return (EOVERFLOW); > + offset += vattr.va_size; This assumes that vattr.va_size is representable as a (non-negative) off_t. E.g., if offset is 1 and vattr.va_size is (uquad_t)-1, then the sum overflows but the overflow is not detected. > break; > case L_SET: > - fp->f_offset = SCARG(uap, offset); > break; > default: > return (EINVAL); > } > + if (no_neg_seek && offset < 0) > + return (EINVAL); Some no_neg_seek conditionals are needed for the overflow checks too. Otherwise seeking from offset OFF_T_MAX to 1 more than that is disallowed for all types of files. The offset overflows, but it only reaches the half way mark in a 64-bit /dev/kmem. > + fp->f_offset = offset; > *(off_t *)(p->p_retval) = fp->f_offset; > return (0); > } kern_lockf.c has some related problems. It doesn't distinguish the EOVERFLOW case from the EINVAL case as is now required by POSIX. POSIX now specifies the behaviour for weird cases like negative lengths (it gives an interval extending from the top down), but I made the overflow checking too strong to permit this. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 15 6: 1:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 7CFA237B40C; Wed, 15 Aug 2001 06:01:11 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.4/8.11.4) id f7FD13U21704; Wed, 15 Aug 2001 17:01:03 +0400 (MSD) (envelope-from ache) Date: Wed, 15 Aug 2001 17:01:01 +0400 From: "Andrey A. Chernov" To: Bruce Evans Cc: arch@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: CFR: lseek() POSIXed patch Message-ID: <20010815170059.A21406@nagual.pp.ru> References: <20010815125248.A2588@nagual.pp.ru> <20010815190108.J19482-100000@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010815190108.J19482-100000@besplex.bde.org> User-Agent: Mutt/1.3.20i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Aug 15, 2001 at 20:15:21 +1000, Bruce Evans wrote: > Something like: > > #define OFF_T_MAX 0x7FFFFFFFFFFFFFFF /* XXX */ > #define OFF_T_MIN (-0x7FFFFFFFFFFFFFFF - 1) /* XXX */ It seems that this defines often needed in many places. What about adding them to /usr/include/machine/limits.h ? Is 0x7fffffffffffffffLL form will be better (i.e. long long)? For other things you mention: I'll try to resolve them. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 15 8: 1:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by hub.freebsd.org (Postfix) with SMTP id 02D3237B405 for ; Wed, 15 Aug 2001 08:01:44 -0700 (PDT) (envelope-from karsten@rohrbach.de) Received: (qmail 28084 invoked by uid 1000); 15 Aug 2001 15:02:04 -0000 Date: Wed, 15 Aug 2001 17:02:04 +0200 From: "Karsten W. Rohrbach" To: Diego Montalvo , freebsd-arm@freebsd.org Cc: freebsd-arch@FreeBSD.org Subject: Re: FreeBSD to go? Message-ID: <20010815170204.G4373@mail.webmonster.de> Mail-Followup-To: "Karsten W. Rohrbach" , Diego Montalvo , freebsd-arm@freebsd.org, freebsd-arch@FreeBSD.org References: <20010813155640.72758.qmail@web13408.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="aYDVKSzuImP48n7V" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010813155640.72758.qmail@web13408.mail.yahoo.com>; from dmontal2@yahoo.com on Mon, Aug 13, 2001 at 08:56:40AM -0700 X-Arbitrary-Number-Of-The-Day: 42 X-URL: http://www.webmonster.de/ X-Disclaimer: My opinions do not necessarily represent those of my employer Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --aYDVKSzuImP48n7V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable you might co-ordinate your efforts with the -arm people, since the iPAQ is a strongarm 1110 based device. thus, informational xpost to -arm. /k Diego Montalvo(dmontal2@yahoo.com)@2001.08.13 08:56:40 +0000: > Hello, >=20 > What are the proper steps in organizing a FreeBSD > development team. I would like to begin development > of a FreeBSD for mobile platforms, example: PocketPC, > Mobile phones, Palm Devices, etc.... =20 >=20 > The link below: is linux on a portable device. > http://waba.sourceforge.net/html/screenshots/iPAQ.html >=20 > Diego=20 >=20 > __________________________________________________ > Do You Yahoo!? > Send instant messages & get email alerts with Yahoo! Messenger. > http://im.yahoo.com/ >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message --=20 > What can you use used tampons for? Tea bags for vampires. KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n= et/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- catch@spam.de GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B= F46 Please do not remove my address from To: and Cc: fields in mailing lists. 1= 0x --aYDVKSzuImP48n7V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7eo7sM0BPTilkv0YRAsIrAJkBSlQxSJGbUi2M7iqGLMRACzs2bQCgtRjo j4OmyIinhtKc+cDtrx3CWaI= =Upqz -----END PGP SIGNATURE----- --aYDVKSzuImP48n7V-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 16 2:49:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mimer.webgiro.com (mailer2.webgiro.com [213.162.131.18]) by hub.freebsd.org (Postfix) with ESMTP id 8D78337B4CF; Thu, 16 Aug 2001 02:48:59 -0700 (PDT) (envelope-from abial@webgiro.com) Received: from webgiro.com (mailer2.webgiro.com [213.162.131.18]) by mimer.webgiro.com (Postfix) with ESMTP id 3C4C368534; Thu, 16 Aug 2001 11:48:49 +0200 (CEST) Message-ID: <3B7B9643.9CA874D9@webgiro.com> Date: Thu, 16 Aug 2001 11:45:40 +0200 From: Andrzej Bialecki Organization: WebGiro AB X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Pentchev Cc: arch@FreeBSD.org, audit@FreeBSD.org Subject: Re: sysctl_register_oid() breakage at unload [PATCH] References: <20010811233452.A510@ringworld.oblivion.bg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Pentchev wrote: > > Hi, > > Well, it seems that I broke things with the panic at attempts to > register oid's higher than the first dynamic oid. Specifically, > this broke the case of unregistering sysctl's, esp. at module unload. > The algorithm described in the sysctl_ctx_free(9) manpage is indeed > so very weird (I won't go so far as calling it 'stupid', because > I cannot really suggest any way to improve it right now). I hear you :-) Actually, I agree with your statement - the current algorithm is a brute force approach. The "proper" way to do it would be to keep a ref count - however, at the time I implemented this I ran out of time. Feel free to finish it. Also, IMHO the border between static and dynamic sysctls should be a much higher number (say, 32767). > So, if a sysctl context is freed, most of the time the first pass > of freeing will fail, and sysctl_ctx_free() will attempt to reregister > the sysctls with the same oid's; this, of course, causes a panic, > because sysctl_register_oid() does not like so high a "static" oid :( > > I just noticed that on my -stable laptop, when I tried to MFC > the patch - my sound driver is only available as a module, and > the kernel panicked at shutdown after attempting to unload it. > For various reasons I cannot run -current on this laptop (not least > because this is the machine I'm using for developing an application > that is supposed to run under -stable), and my -current box did not > really have any need for loadable modules, so that's how this slipped > in unnoticed :( > > So here's a proposed fix: add a "this is actually a re-registering, > stay cool" flag to sysctl_register_oid(), and update all the calls > to it that I could find under src/sys. This flag needs only be set > in sysctl_ctx_free(), all the other callers put a 0. ...having in mind that this is just a bandaid around a suboptimal design. Well, come to that, I'm not sure if we should further uglify the code with this patch... It really should use ref counts instead. Depending on my daytime job, I may try to fix it - otherwise feel free to do it yourself. -- Andrzej // ---------------------------------------------------------------- // Andrzej Bialecki , Chief System Architect // WebGiro AB, Sweden (http://www.webgiro.com) // ---------------------------------------------------------------- // FreeBSD developer (http://www.freebsd.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 16 3:35: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from arb.arb.za.net (arb.arb.za.net [196.7.148.4]) by hub.freebsd.org (Postfix) with ESMTP id D031E37B40D for ; Thu, 16 Aug 2001 03:34:58 -0700 (PDT) (envelope-from mark@grondar.za) Received: (from uucp@localhost) by arb.arb.za.net (8.11.3/8.11.3) with UUCP id f7GAYvu01926 for arch@freebsd.org; Thu, 16 Aug 2001 12:34:57 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.5/8.11.4) with ESMTP id f7GAAsK68419 for ; Thu, 16 Aug 2001 11:10:54 +0100 (BST) (envelope-from mark@grondar.za) Message-Id: <200108161010.f7GAAsK68419@grimreaper.grondar.za> To: arch@freebsd.org Subject: Style 9 nitpicking question Date: Thu, 16 Aug 2001 11:10:53 +0100 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi A piece of style(9) says: static void usage() { /* Insert an empty line if the function has no local variables. */ Use printf(3), not fputs/puts/putchar/whatever; it's faster and usually cleaner, not to mention avoiding stupid bugs. [ snip ] "usage: f [-aDde] [-b b_arg] [-m m_arg] req1 req2 [opt1 [opt2]]\n" "usage: f [-a | -b] [-c [-dEe] [-n number]]\n" (void)fprintf(stderr, "usage: f [-ab]\n"); exit(EX_USAGE); } Questions: 1) That "(void)" is useless by any metric that I am able to determine (WARNS=2, BDECFLAGS etc), and gets in the way of linting. Is there any reason to continue to advocate its use by this example? There is no other reference to "voiding-out" of return values. 2) Is this (fprintf(stderr, "...", ...); exit(n);) really better than errx(1, "...", ...); ? Any objections to changing the (void)fprintf(stderr, "usage: f [-ab]\n"); exit(EX_USAGE); to errx(EX_USAGE, "usage: f [-ab]\n"); ?? M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 16 3:47:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 16DA537B409 for ; Thu, 16 Aug 2001 03:47:26 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f7GAksM81600; Thu, 16 Aug 2001 13:46:54 +0300 (EEST) (envelope-from ru) Date: Thu, 16 Aug 2001 13:46:54 +0300 From: Ruslan Ermilov To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: Style 9 nitpicking question Message-ID: <20010816134654.C73183@sunbay.com> References: <200108161010.f7GAAsK68419@grimreaper.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108161010.f7GAAsK68419@grimreaper.grondar.za>; from mark@grondar.za on Thu, Aug 16, 2001 at 11:10:53AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Aug 16, 2001 at 11:10:53AM +0100, Mark Murray wrote: [...] > 2) Is this (fprintf(stderr, "...", ...); exit(n);) really better than > errx(1, "...", ...); ? > > Any objections to changing the > > (void)fprintf(stderr, "usage: f [-ab]\n"); > exit(EX_USAGE); > > to > > errx(EX_USAGE, "usage: f [-ab]\n"); > Yes, at least in one respect. err(3) is non-standard. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 16 8:17: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id B15BA37B401 for ; Thu, 16 Aug 2001 08:17:02 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA09325; Fri, 17 Aug 2001 01:16:39 +1000 Date: Fri, 17 Aug 2001 01:16:37 +1000 (EST) From: Bruce Evans X-X-Sender: To: Mark Murray Cc: Subject: Re: Style 9 nitpicking question In-Reply-To: <200108161010.f7GAAsK68419@grimreaper.grondar.za> Message-ID: <20010817005031.S29341-100000@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 16 Aug 2001, Mark Murray wrote: > A piece of style(9) says: > > > > static void > usage() > { > /* Insert an empty line if the function has no local variables. */ > > Use printf(3), not fputs/puts/putchar/whatever; it's faster and usually > cleaner, not to mention avoiding stupid bugs. > > [ snip ] > > "usage: f [-aDde] [-b b_arg] [-m m_arg] req1 req2 [opt1 [opt2]]\n" > "usage: f [-a | -b] [-c [-dEe] [-n number]]\n" > > (void)fprintf(stderr, "usage: f [-ab]\n"); > exit(EX_USAGE); > } > > > > Questions: > > 1) That "(void)" is useless by any metric that I am able to determine > (WARNS=2, BDECFLAGS etc), and gets in the way of linting. Is there > any reason to continue to advocate its use by this example? There > is no other reference to "voiding-out" of return values. It by prevents warnings like the following from `lint -h': "snprintf returns a value which is sometimes ignored" "snprintf returns a value which is always ignored" This is the opposite of getting in the way of linting. > 2) Is this (fprintf(stderr, "...", ...); exit(n);) really better than > errx(1, "...", ...); ? Yes. The former is more portable, and prints the program name in the usual place (after "usage: "). > Any objections to changing the > > (void)fprintf(stderr, "usage: f [-ab]\n"); > exit(EX_USAGE); > > to > > errx(EX_USAGE, "usage: f [-ab]\n"); Yes :-). The second form here has the additional bug of printing the program name twice (perhaps different names if the binary is linked). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 16 12:18:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from arb.arb.za.net (arb.arb.za.net [196.7.148.4]) by hub.freebsd.org (Postfix) with ESMTP id 843A237B408 for ; Thu, 16 Aug 2001 12:18:09 -0700 (PDT) (envelope-from mark@grondar.za) Received: (from uucp@localhost) by arb.arb.za.net (8.11.3/8.11.3) with UUCP id f7GJHrE49651; Thu, 16 Aug 2001 21:17:53 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.5/8.11.4) with ESMTP id f7GFpLK72129; Thu, 16 Aug 2001 16:51:22 +0100 (BST) (envelope-from mark@grondar.za) Message-Id: <200108161551.f7GFpLK72129@grimreaper.grondar.za> To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: Style 9 nitpicking question References: <20010817005031.S29341-100000@besplex.bde.org> In-Reply-To: <20010817005031.S29341-100000@besplex.bde.org> ; from Bruce Evans "Fri, 17 Aug 2001 01:16:37 +1000." Date: Thu, 16 Aug 2001 16:51:20 +0100 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Questions: > > > > 1) That "(void)" is useless by any metric that I am able to determine > > (WARNS=2, BDECFLAGS etc), and gets in the way of linting. Is there > > any reason to continue to advocate its use by this example? There > > is no other reference to "voiding-out" of return values. > > It by prevents warnings like the following from `lint -h': > > "snprintf returns a value which is sometimes ignored" > "snprintf returns a value which is always ignored" Hmm - in the linting that I have done, I've told lint that ignoring the return value of ${THESE} functions is OK. (THESE = str* *printf, *scanf and a few others) > This is the opposite of getting in the way of linting. Sorta :-) Its often not a useful warning (most particularly for certain functions), and the (void) cast offends me because it is useless and obfuscating. > > 2) Is this (fprintf(stderr, "...", ...); exit(n);) really better than > > errx(1, "...", ...); ? > > Yes. The former is more portable, and prints the program name in the > usual place (after "usage: "). OK. > > Any objections to changing the > > > > (void)fprintf(stderr, "usage: f [-ab]\n"); > > exit(EX_USAGE); > > > > to > > > > errx(EX_USAGE, "usage: f [-ab]\n"); > > Yes :-). The second form here has the additional bug of printing the > program name twice (perhaps different names if the binary is linked). OK. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 16 21:13:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp4.ihug.co.nz (smtp4.ihug.co.nz [203.109.252.5]) by hub.freebsd.org (Postfix) with ESMTP id 7C7EA37B405 for ; Thu, 16 Aug 2001 21:13:21 -0700 (PDT) (envelope-from anru@ihug.co.nz) Received: from smtp.ihug.co.nz (p406-apx1.akl.ihug.co.nz [203.173.193.152]) by smtp4.ihug.co.nz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id QAA11279 for ; Fri, 17 Aug 2001 16:13:19 +1200 X-Authentication-Warning: smtp4.ihug.co.nz: Host p406-apx1.akl.ihug.co.nz [203.173.193.152] claimed to be smtp.ihug.co.nz Message-Id: <998021575.520@ihug.co.nz> Date: Fri, 17 Aug 2001 16:12:55 1200 To: freebsd-arch@freebsd.org From: anru@ihug.co.nz (John Zheng) Subject: Denial of Service Research MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dear Sir/Madam My name is John Zheng. I sent this email to you a couple days ago to invite you to my on-line survey. This is a friendly reminder in case you missed out the previous one because the web server was affected due to a power failure 2 days ago. I promise I won't bother you again! We are students at the UNITEC Institute of Technology (New Zealand), and currently working on a DoS/DDoS (Denial of service) research project, as required for our degree. For this project we conduct research on the analysis of the DoS/DDoS technologies and threats, as well as anti DoS/DDoS tools. As part of this research, we found your email on the internet. You could be of great help to us if you could fill out our on-line survey, which we have prepared for this project. In return, we will email you the summarized outcome of the project if you do provide your email address in the survey form. Please find the survey here: http://hyperdisc.unitec.ac.nz/dos_research/ The information you give us will be analyzed and results will be presented in an anonymous, generic form. Please let us assure you that all your information will remain strictly confidential. Thank you very much for assisting us! If you need to contact us, please email to e_URL@hotmail.com Best Regards Leon & John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 16 22:38:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id ED97337B40D for ; Thu, 16 Aug 2001 22:38:26 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f7H5cPq19342; Thu, 16 Aug 2001 23:38:26 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f7H5cOW38477; Thu, 16 Aug 2001 23:38:25 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108170538.f7H5cOW38477@harmony.village.org> To: Mark Murray Subject: Re: Style 9 nitpicking question Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Aug 2001 11:10:53 BST." <200108161010.f7GAAsK68419@grimreaper.grondar.za> References: <200108161010.f7GAAsK68419@grimreaper.grondar.za> Date: Thu, 16 Aug 2001 23:38:24 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200108161010.f7GAAsK68419@grimreaper.grondar.za> Mark Murray writes: : 1) That "(void)" is useless by any metric that I am able to determine : (WARNS=2, BDECFLAGS etc), and gets in the way of linting. Is there : any reason to continue to advocate its use by this example? There : is no other reference to "voiding-out" of return values. lint complains on old systems. : 2) Is this (fprintf(stderr, "...", ...); exit(n);) really better than : errx(1, "...", ...); ? : : Any objections to changing the : : (void)fprintf(stderr, "usage: f [-ab]\n"); : exit(EX_USAGE); : : to : : errx(EX_USAGE, "usage: f [-ab]\n"); : : ?? Not from me. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 16 23:33:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 2662637B40C for ; Thu, 16 Aug 2001 23:33:13 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA22232; Fri, 17 Aug 2001 16:31:38 +1000 Date: Fri, 17 Aug 2001 16:31:36 +1000 (EST) From: Bruce Evans X-X-Sender: To: Mark Murray Cc: Subject: Re: Style 9 nitpicking question In-Reply-To: <200108161551.f7GFpLK72129@grimreaper.grondar.za> Message-ID: <20010817162340.O34503-100000@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 16 Aug 2001, Mark Murray wrote: > > > Questions: > > > > > > 1) That "(void)" is useless by any metric that I am able to determine > > > (WARNS=2, BDECFLAGS etc), and gets in the way of linting. Is there > > > any reason to continue to advocate its use by this example? There > > > is no other reference to "voiding-out" of return values. > > > > It by prevents warnings like the following from `lint -h': > > > > "snprintf returns a value which is sometimes ignored" > > "snprintf returns a value which is always ignored" > > Hmm - in the linting that I have done, I've told lint that ignoring > the return value of ${THESE} functions is OK. > > (THESE = str* *printf, *scanf and a few others) Ignoring the result of *printf is not always OK, and ignoring the result of *scanf is almost never OK. > > This is the opposite of getting in the way of linting. > > Sorta :-) Its often not a useful warning (most particularly for > certain functions), and the (void) cast offends me because it is > useless and obfuscating. I don't like it much either, but it's normal practice in BSD code. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 16 23:59: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id AC71337B406 for ; Thu, 16 Aug 2001 23:59:06 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id B769E81D07; Fri, 17 Aug 2001 01:59:06 -0500 (CDT) Date: Fri, 17 Aug 2001 01:59:06 -0500 From: Alfred Perlstein To: Bruce Evans Cc: Mark Murray , arch@FreeBSD.ORG Subject: Re: Style 9 nitpicking question Message-ID: <20010817015906.Q38066@elvis.mu.org> References: <200108161551.f7GFpLK72129@grimreaper.grondar.za> <20010817162340.O34503-100000@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010817162340.O34503-100000@besplex.bde.org>; from bde@zeta.org.au on Fri, Aug 17, 2001 at 04:31:36PM +1000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Bruce Evans [010817 01:40] wrote: > On Thu, 16 Aug 2001, Mark Murray wrote: > > > Sorta :-) Its often not a useful warning (most particularly for > > certain functions), and the (void) cast offends me because it is > > useless and obfuscating. > > I don't like it much either, but it's normal practice in BSD code. Actually it's quite useful, it means: "I the author of this code am fully aware that this function returns a value, however I know that it either will always have a certain outcome, or that the outcome doesn't matter because I'm attempting to salvage something, or that at this point a failure is of no concern." I'm sure one could add to that list, imo it's good programming style to do so when justified, however it's not acceptable just to do that in order to give the false impression of the previous statements. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 17 0:22:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 41D5237B405; Fri, 17 Aug 2001 00:21:49 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f7H7LnM51364; Fri, 17 Aug 2001 00:21:49 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 0BCD63811; Fri, 17 Aug 2001 00:21:49 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Mitsuru IWASAKI Cc: arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit In-Reply-To: <20010809035801V.iwasaki@jp.FreeBSD.org> Date: Fri, 17 Aug 2001 00:21:49 -0700 From: Peter Wemm Message-Id: <20010817072149.0BCD63811@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mitsuru IWASAKI wrote: > Hi, I've found a report in Japanese mailing list that CR4.PGE seems to > be enabled before CR0.PG in locore.s. This was originally reported by > Kumabuchi-san (Thanks!). > > According to developer's manual from Intel site, > ftp://download.intel.com/design/PentiumII/manuals/24319202.pdf > ---- > 2.5. CONTROL REGISTERS > [snip] > PGE > (2-17) > Page Global Enable (bit 7 of CR4). (Introduced in the P6 family > processors.) Enables the global page feature when set; disables the > global page feature when clear. [snip] In addition, the bit must not > ^^^^^^^^^^^^^^^^ > be enabled before paging is enabled via CR0.PG. Program correctness > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > may be affected by reversing this sequence, and processor performance > will be impacted. > ---- > > Currently, we enable CR4.PGE bit in create_pagetables, then enable > CR0.PG in locore.s. This seems to violate Intel's note. > > I've made patches for this, moving CR4.PGE enabling code to just > before calling init386(). > > Index: locore.s > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/locore.s,v > retrieving revision 1.144 > diff -u -r1.144 locore.s > --- locore.s 2001/07/12 06:32:50 1.144 > +++ locore.s 2001/08/08 17:49:28 > @@ -374,6 +374,12 @@ > movl IdlePTD,%esi > movl %esi,PCB_CR3(%eax) > > + testl $CPUID_PGE, R(cpu_feature) > + jz 1f > + movl %cr4, %eax > + orl $CR4_PGE, %eax > + movl %eax, %cr4 > +1: > pushl physfree /* value of first for init386(f irst) */ > call init386 /* wire 386 chip for unix opera tion */ > > @@ -718,13 +724,6 @@ > */ > > create_pagetables: > - > - testl $CPUID_PGE, R(cpu_feature) > - jz 1f > - movl %cr4, %eax > - orl $CR4_PGE, %eax > - movl %eax, %cr4 > -1: > > /* Find end of kernel image (rounded up to a page boundary). */ > movl $R(_end),%esi This part is fine. However: > Also I have another thing to be confirmed. Should we utilize TLB by > enabling PGE bit at very later stage? I think it would be more > efficient to cache page entries with G flag in multi-user environment, > not in kernel bootstrap. If we enable PGE bit in locore.s, TLB could > be occupied by entries which is referenced by initialization code > (yes, most of them are executed only once). > # but I could be wrong... The G bit does not "lock" the TLB entries in. All it does is stop unnecessary flushes when %cr3 is changed. If entries are not used for a short while, they will be recycled when the TLB slot is needed for something else soon enough. ie: this should not be a problem. > Anyway, patch for this is attached here. Regardless of my doubts above, I do have a problem with the patch... It only works for the PPro/p2/p3 and not the p4. Is this intentional? All have the CPUID_PGE bit. I think the test for cpu_id & 0x600 is bogus and should be removed. > Thanks. > > Index: initcpu.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/initcpu.c,v > retrieving revision 1.29 > diff -u -r1.29 initcpu.c > --- initcpu.c 2001/07/13 11:23:06 1.29 > +++ initcpu.c 2001/08/08 15:35:51 > @@ -847,3 +847,23 @@ > printf("CR0=%x\n", cr0); > } > #endif /* DDB */ > + > +/* > + * Enable CR4.PGE after kernel bootstrap. > + */ > + > +static void > +enable_i686_pge(void *unused) > +{ > + > + if ((cpu_feature & CPUID_PGE) && > + (cpu_id & 0xf00) == 0x600) { > + load_cr4(rcr4() | CR4_PGE); > + if (bootverbose) { > + printf("P6 family processor PGE on\n"); > + } > + } > +} > + > +SYSINIT(initcpu, SI_SUB_RUN_SCHEDULER, SI_ORDER_FIRST, enable_i686_pge, NULL ) > + > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 17 5:59:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id BEF7837B40D for ; Fri, 17 Aug 2001 05:59:12 -0700 (PDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.5/8.11.5) with SMTP id f7HCxBx07601 for ; Fri, 17 Aug 2001 08:59:11 -0400 (EDT) (envelope-from arr@watson.org) Date: Fri, 17 Aug 2001 08:59:10 -0400 (EDT) From: "Andrew R. Reiter" To: arch@freebsd.org Subject: pool(9) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hey, I was wondering if anyone had taken an interest in pool(9) from NetBSD -- and now in OpenBSD. To explain what it is, I might as well quote a man page (I know I'd mess it up ;-), a few more comments below it): DESCRIPTION These utility routines provide management of pools of fixed-sized areas of memory. Resource pools set aside an amount of memory for exclusive use by the resource pool owner. This can be used by applications to guarantee the availability of a minimum amount of memory needed to continue operation independent of the memory resources currently available from the system-wide memory allocator (malloc(9)). The pool manager can optionally obtain temporary memory by calling the palloc() function passed to pool_create(), for extra pool items in case the number of allocations exceeds the nominal number of pool items managed by a pool resource. This temporary memory will be automatically returned to the system at a later time. -- I realize the state of -current and all that is going on, especially with trying to get a 5.0 snap done by the end of the year, but I'd be interested in seeing it in perhaps a later 5.x? Also, in that 5.x, I'd be interested in seeing it actually being _used_ by certain kernel resources -- perhaps VFS related things? If one is so inclined, grep for pool (or it's functions) in the NetBSD and/or OpenBSD sys/kern director to see where they are using it in there. Anyway, any interest in this? Sounds kind of nice, but perhaps we already have a similar system in place that I am missing? Cheers, Andrew *-------------................................................. | Andrew R. Reiter | arr@fledge.watson.org | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 17 8:35: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id DD73F37B401 for ; Fri, 17 Aug 2001 08:34:57 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f7HFYtk112060; Fri, 17 Aug 2001 11:34:55 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010817015906.Q38066@elvis.mu.org> References: <200108161551.f7GFpLK72129@grimreaper.grondar.za> <20010817162340.O34503-100000@besplex.bde.org> <20010817015906.Q38066@elvis.mu.org> Date: Fri, 17 Aug 2001 11:34:53 -0400 To: Alfred Perlstein From: Garance A Drosihn Subject: Re: Style 9 nitpicking question Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 1:59 AM -0500 8/17/01, Alfred Perlstein wrote: >Actually it's quite useful, it means: > >"I the author of this code am fully aware that this function returns >a value, however I know that it either will always have a certain >outcome, or that the outcome doesn't matter because I'm attempting >to salvage something, or that at this point a failure is of no >concern." Or it means: "I copied this code from some other section, and whoever wrote that section put these stupid voids there." :-) -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 17 9:10:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 5CA1437B40D for ; Fri, 17 Aug 2001 09:10:18 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA23034; Fri, 17 Aug 2001 09:16:36 -0700 (PDT) Date: Fri, 17 Aug 2001 09:16:36 -0700 (PDT) From: Julian Elischer To: "Andrew R. Reiter" Cc: arch@freebsd.org Subject: Re: pool(9) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG so exactly how many kernel memory allocators do we need? zalloc, malloc, mbuf_alloc, kmem_alloc, bus_space_(mumble)_alloc, and now pool (shoulkd end in 'alloc :-) not to mention various private allocators, On Fri, 17 Aug 2001, Andrew R. Reiter wrote: > Hey, > > I was wondering if anyone had taken an interest in pool(9) from NetBSD -- > and now in OpenBSD. To explain what it is, I might as well quote a man > page (I know I'd mess it up ;-), a few more comments below it): > > DESCRIPTION > These utility routines provide management of pools of fixed-sized > areas of memory. Resource pools set aside an amount of memory for > exclusive use by the resource pool owner. This can be used by > applications to guarantee the availability of a minimum amount of memory > needed to continue operation independent of the memory resources currently > available from the system-wide memory allocator (malloc(9)). The pool manager > can optionally obtain temporary memory by calling the palloc() function > passed to pool_create(), for extra pool items in case the number of > allocations exceeds the nominal number of pool items managed by a pool > resource. This temporary memory will be automatically returned to the > system at a later time. > > -- > > I realize the state of -current and all that is going on, especially with > trying to get a 5.0 snap done by the end of the year, but I'd be > interested in seeing it in perhaps a later 5.x? Also, in that 5.x, I'd be > interested in seeing it actually being _used_ by certain kernel resources > -- perhaps VFS related things? If one is so inclined, grep for pool (or > it's functions) in the NetBSD and/or OpenBSD sys/kern director to see > where they are using it in there. > > Anyway, any interest in this? Sounds kind of nice, but perhaps we already > have a similar system in place that I am missing? > > Cheers, > > Andrew > > *-------------................................................. > | Andrew R. Reiter > | arr@fledge.watson.org > | "It requires a very unusual mind > | to undertake the analysis of the obvious" -- A.N. Whitehead > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 17 9:28:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5D0CC37B40E for ; Fri, 17 Aug 2001 09:28:21 -0700 (PDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.5/8.11.5) with SMTP id f7HGSIn09786; Fri, 17 Aug 2001 12:28:18 -0400 (EDT) (envelope-from arr@watson.org) Date: Fri, 17 Aug 2001 12:28:18 -0400 (EDT) From: "Andrew R. Reiter" To: Julian Elischer Cc: arch@freebsd.org Subject: Re: pool(9) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Good point. But, wouldn't it be nicer to have all those different _alloc's being part of a same interface known as pool? Please _smack_ me if Im wrong on this -- I take being wrong fairly well :-) cheers, andrew On Fri, 17 Aug 2001, Julian Elischer wrote: :so exactly how many kernel memory allocators do we need? : :zalloc, malloc, mbuf_alloc, kmem_alloc, bus_space_(mumble)_alloc, and now :pool (shoulkd end in 'alloc :-) :not to mention various private allocators, : : :On Fri, 17 Aug 2001, Andrew R. Reiter wrote: : :> Hey, :> :> I was wondering if anyone had taken an interest in pool(9) from NetBSD -- :> and now in OpenBSD. To explain what it is, I might as well quote a man :> page (I know I'd mess it up ;-), a few more comments below it): :> :> DESCRIPTION :> These utility routines provide management of pools of fixed-sized :> areas of memory. Resource pools set aside an amount of memory for :> exclusive use by the resource pool owner. This can be used by :> applications to guarantee the availability of a minimum amount of memory :> needed to continue operation independent of the memory resources currently :> available from the system-wide memory allocator (malloc(9)). The pool manager :> can optionally obtain temporary memory by calling the palloc() function :> passed to pool_create(), for extra pool items in case the number of :> allocations exceeds the nominal number of pool items managed by a pool :> resource. This temporary memory will be automatically returned to the :> system at a later time. :> :> -- :> :> I realize the state of -current and all that is going on, especially with :> trying to get a 5.0 snap done by the end of the year, but I'd be :> interested in seeing it in perhaps a later 5.x? Also, in that 5.x, I'd be :> interested in seeing it actually being _used_ by certain kernel resources :> -- perhaps VFS related things? If one is so inclined, grep for pool (or :> it's functions) in the NetBSD and/or OpenBSD sys/kern director to see :> where they are using it in there. :> :> Anyway, any interest in this? Sounds kind of nice, but perhaps we already :> have a similar system in place that I am missing? :> :> Cheers, :> :> Andrew :> :> *-------------................................................. :> | Andrew R. Reiter :> | arr@fledge.watson.org :> | "It requires a very unusual mind :> | to undertake the analysis of the obvious" -- A.N. Whitehead :> :> :> To Unsubscribe: send mail to majordomo@FreeBSD.org :> with "unsubscribe freebsd-arch" in the body of the message :> : : *-------------................................................. | Andrew R. Reiter | arr@fledge.watson.org | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 17 9:30:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 5F62B37B405 for ; Fri, 17 Aug 2001 09:30:12 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.4/8.11.4) with ESMTP id f7HGU1n23108; Fri, 17 Aug 2001 18:30:01 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: "Andrew R. Reiter" , arch@FreeBSD.ORG Subject: Re: pool(9) In-Reply-To: Your message of "Fri, 17 Aug 2001 09:16:36 PDT." Date: Fri, 17 Aug 2001 18:30:01 +0200 Message-ID: <23106.998065801@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Ju lian Elischer writes: >so exactly how many kernel memory allocators do we need? > >zalloc, malloc, mbuf_alloc, kmem_alloc, bus_space_(mumble)_alloc, and now >pool (shoulkd end in 'alloc :-) >not to mention various private allocators, Yeah, zmore /usr/share/doc/papers/kernmalloc.ascii.gz is a good read. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 17 11:30:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id AB8DC37B408 for ; Fri, 17 Aug 2001 11:30:51 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 3E84981D0E; Fri, 17 Aug 2001 13:30:41 -0500 (CDT) Date: Fri, 17 Aug 2001 13:30:41 -0500 From: Alfred Perlstein To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Style 9 nitpicking question Message-ID: <20010817133041.T38066@elvis.mu.org> References: <200108161551.f7GFpLK72129@grimreaper.grondar.za> <20010817162340.O34503-100000@besplex.bde.org> <20010817015906.Q38066@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drosih@rpi.edu on Fri, Aug 17, 2001 at 11:34:53AM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Garance A Drosihn [010817 10:34] wrote: > At 1:59 AM -0500 8/17/01, Alfred Perlstein wrote: > >Actually it's quite useful, it means: > > > >"I the author of this code am fully aware that this function returns > >a value, however I know that it either will always have a certain > >outcome, or that the outcome doesn't matter because I'm attempting > >to salvage something, or that at this point a failure is of no > >concern." > > Or it means: > "I copied this code from some other section, and whoever wrote > that section put these stupid voids there." > > :-) Imitation is the sincerest form of flattery. Don't shoot a mime just because he can't do the vocals. :) -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 17 22:22:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ws1-2.us4.outblaze.com (205-158-62-54.outblaze.com [205.158.62.54]) by hub.freebsd.org (Postfix) with SMTP id 8660E37B401 for ; Fri, 17 Aug 2001 22:22:19 -0700 (PDT) (envelope-from amitshah@techie.com) Received: (qmail 5066 invoked by uid 1001); 18 Aug 2001 05:22:19 -0000 Message-ID: <20010818052219.5065.qmail@mail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from ws1-2.us4.outblaze.com for [192.168.1.104, 203.197.87.98] via web-mailer on Sat, 18 Aug 2001 10:22:19 +0500 From: "Amit Shah" To: freebsd-arch@freebsd.org Date: Sat, 18 Aug 2001 10:22:19 +0500 Subject: threaded device drivers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I wanted to know if threading of device drivers is supported in freebsd.... if it is not, I would like to do it as a project with some of my colleagues... can someone give me some info on this? Also, tell me if it would be beneficial (and in what way) to do this on freebsd. -- _______________________________________________ FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Talk More, Pay Less with Net2Phone Direct(R), up to 1500 minutes free! http://www.net2phone.com/cgi-bin/link.cgi?143 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 18 1: 4:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 2D0C637B40C for ; Sat, 18 Aug 2001 01:04:43 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f7I88mJ08635; Sat, 18 Aug 2001 01:08:48 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108180808.f7I88mJ08635@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Amit Shah" Cc: freebsd-arch@freebsd.org Subject: Re: threaded device drivers In-reply-to: Your message of "Sat, 18 Aug 2001 10:22:19 +0500." <20010818052219.5065.qmail@mail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Aug 2001 01:08:48 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I wanted to know if threading of device drivers is supported in freebsd.... i > f it is not, I would like to do it as a project with some of my colleagues... > can someone give me some info on this? Also, tell me if it would be benefici > al (and in what way) to do this on freebsd. "Threading device drivers" is a bit of an ambiguous description. There is a lot of abuse of threaded design in device drivers for operating sytems like Windows; if you're talking about this sort of thing, then no, it would not be beneficial at all. The FreeBSD device driver model is very "thin"; drivers don't typically do very much work, and so code paths tend to run to completion. For blocking conditions, one typically uses a callback rather than putting a thread to sleep. In -current, drivers that want threads can spawn them off; where it's absolutely necessary it's usually a driver-specific issue rather than being something that could be implemented in any more generic a fashion. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 18 1:18:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id E1F7C37B40C; Sat, 18 Aug 2001 01:18:11 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f7I8HoI55273; Sat, 18 Aug 2001 01:17:50 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Sat, 18 Aug 2001 01:17:50 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Mike Smith Cc: Amit Shah , freebsd-arch@FreeBSD.ORG Subject: Re: threaded device drivers In-Reply-To: <200108180808.f7I88mJ08635@mass.dis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > In -current, drivers that want threads can spawn them off; where it's > absolutely necessary it's usually a driver-specific issue rather than > being something that could be implemented in any more generic a fashion. > An example of this is the QLogic driver (isp(4)) spawns a thread that is used to rebuild loop state and rescan the loop and fabric port databases after an asynchronous event brings a notification of change. Threads are not nearly lightweight enough yet to provide, say, offlevel processing such as RSX-11 or VMS provided. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 18 3:10: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 46F8637B409; Sat, 18 Aug 2001 03:09:56 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f7IAE4J10122; Sat, 18 Aug 2001 03:14:05 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108181014.f7IAE4J10122@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: Mike Smith , Amit Shah , freebsd-arch@FreeBSD.ORG Subject: Re: threaded device drivers In-reply-to: Your message of "Sat, 18 Aug 2001 01:17:50 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Aug 2001 03:14:04 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > An example of this is the QLogic driver (isp(4)) spawns a thread that is used > to rebuild loop state and rescan the loop and fabric port databases after an > asynchronous event brings a notification of change. You can do this with the taskqueue mechanism too; since you have a notification event. > Threads are not nearly lightweight enough yet to provide, say, offlevel > processing such as RSX-11 or VMS provided. Taskqueue does this well too. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 18 8:38:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 7992737B401; Sat, 18 Aug 2001 08:38:10 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f7IFc9I59641; Sat, 18 Aug 2001 08:38:09 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Sat, 18 Aug 2001 08:38:09 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Mike Smith Cc: Amit Shah , freebsd-arch@FreeBSD.ORG Subject: Re: threaded device drivers In-Reply-To: <200108181014.f7IAE4J10122@mass.dis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 18 Aug 2001, Mike Smith wrote: > > An example of this is the QLogic driver (isp(4)) spawns a thread that is used > > to rebuild loop state and rescan the loop and fabric port databases after an > > asynchronous event brings a notification of change. > > You can do this with the taskqueue mechanism too; since you have a > notification event. No, that's not what I wanted to do. I wanted full process context that allows me to do tsleeps, etc., although it could probably done via a taskq mechanism if I went to the effort to rewrite it as a set of taskqueue calls while in 'rebuild' state. > > > Threads are not nearly lightweight enough yet to provide, say, offlevel > > processing such as RSX-11 or VMS provided. > > Taskqueue does this well too. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 18 12:48:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 9656337B405; Sat, 18 Aug 2001 12:48:41 -0700 (PDT) (envelope-from hch@ns.caldera.de) Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f7IJmQc09991; Sat, 18 Aug 2001 21:48:26 +0200 Date: Sat, 18 Aug 2001 21:48:26 +0200 From: Christoph Hellwig To: Matthew Jacob Cc: Mike Smith , Amit Shah , freebsd-arch@FreeBSD.ORG Subject: Re: threaded device drivers Message-ID: <20010818214826.B8481@caldera.de> References: <200108181014.f7IAE4J10122@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Sat, Aug 18, 2001 at 08:38:09AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Aug 18, 2001 at 08:38:09AM -0700, Matthew Jacob wrote: > No, that's not what I wanted to do. I wanted full process context that allows > me to do tsleeps, etc., although it could probably done via a taskq mechanism > if I went to the effort to rewrite it as a set of taskqueue calls while in > 'rebuild' state. You might want to take a look at Linux's schedule_task family of cuntions (kernel/context.c) - it should be straight forward to implement for FreeBSD. Christoph -- Christoph Hellwig Kernel Engineer Unix/Linux Integration Caldera Deutschland GmbH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 18 12:50:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 66DFC37B413; Sat, 18 Aug 2001 12:50:08 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f7IJo5I60844; Sat, 18 Aug 2001 12:50:05 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Sat, 18 Aug 2001 12:50:04 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Christoph Hellwig Cc: Mike Smith , Amit Shah , freebsd-arch@FreeBSD.ORG Subject: Re: threaded device drivers In-Reply-To: <20010818214826.B8481@caldera.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG No, I'm perfectly happy with the current thread mechanism, which should improve over time. On Sat, 18 Aug 2001, Christoph Hellwig wrote: > On Sat, Aug 18, 2001 at 08:38:09AM -0700, Matthew Jacob wrote: > > No, that's not what I wanted to do. I wanted full process context that allows > > me to do tsleeps, etc., although it could probably done via a taskq mechanism > > if I went to the effort to rewrite it as a set of taskqueue calls while in > > 'rebuild' state. > > You might want to take a look at Linux's schedule_task family of cuntions > (kernel/context.c) - it should be straight forward to implement for FreeBSD. > > Christoph > > -- > Christoph Hellwig > Kernel Engineer Unix/Linux Integration > Caldera Deutschland GmbH > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 18 12:59:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id D320F37B405; Sat, 18 Aug 2001 12:53:55 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f7IJuJS00930; Sat, 18 Aug 2001 12:56:20 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108181956.f7IJuJS00930@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Christoph Hellwig Cc: Matthew Jacob , Mike Smith , Amit Shah , freebsd-arch@FreeBSD.ORG Subject: Re: threaded device drivers In-reply-to: Your message of "Sat, 18 Aug 2001 21:48:26 +0200." <20010818214826.B8481@caldera.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Aug 2001 12:56:19 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Sat, Aug 18, 2001 at 08:38:09AM -0700, Matthew Jacob wrote: > > No, that's not what I wanted to do. I wanted full process context that allo > ws > > me to do tsleeps, etc., although it could probably done via a taskq mechani > sm > > if I went to the effort to rewrite it as a set of taskqueue calls while in > > 'rebuild' state. > > You might want to take a look at Linux's schedule_task family of cuntions > (kernel/context.c) - it should be straight forward to implement for FreeBSD. But entirely unnecessary, since we can already create threads in the kernel, as I pointed out earlier. See the kthread* family of functions. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 18 13:13:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 1FA3B37B414; Sat, 18 Aug 2001 13:08:25 -0700 (PDT) (envelope-from hch@ns.caldera.de) Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f7IK8OW12821; Sat, 18 Aug 2001 22:08:24 +0200 Date: Sat, 18 Aug 2001 22:08:23 +0200 From: Christoph Hellwig To: Mike Smith Cc: Christoph Hellwig , Matthew Jacob , Amit Shah , freebsd-arch@FreeBSD.ORG Subject: Re: threaded device drivers Message-ID: <20010818220823.C8481@caldera.de> References: <20010818214826.B8481@caldera.de> <200108181956.f7IJuJS00930@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108181956.f7IJuJS00930@mass.dis.org>; from msmith@FreeBSD.ORG on Sat, Aug 18, 2001 at 12:56:19PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Aug 18, 2001 at 12:56:19PM -0700, Mike Smith wrote: > > You might want to take a look at Linux's schedule_task family of cuntions > > (kernel/context.c) - it should be straight forward to implement for FreeBSD. > > But entirely unnecessary, since we can already create threads in the > kernel, as I pointed out earlier. See the kthread* family of functions. I know kthread ;) The differnce is just that you need an entire thread this way - threads are eating up far too much ressources (e.g. kernel stack) for certain types of problems. A way to just execute some function in user context is a very nice appropeach for lots of the smaller stuff. Some people might also remeber NetWare's WorkToDo's that can do this stuff combines with wait queues. Christoph -- Christoph Hellwig Kernel Engineer Unix/Linux Integration Caldera Deutschland GmbH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 18 13:22:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 6864337B409; Sat, 18 Aug 2001 13:22:10 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f7IKM7I61050; Sat, 18 Aug 2001 13:22:07 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Sat, 18 Aug 2001 13:22:07 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Christoph Hellwig Cc: Mike Smith , Amit Shah , freebsd-arch@FreeBSD.ORG Subject: Re: threaded device drivers In-Reply-To: <20010818220823.C8481@caldera.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 18 Aug 2001, Christoph Hellwig wrote: > On Sat, Aug 18, 2001 at 12:56:19PM -0700, Mike Smith wrote: > > > You might want to take a look at Linux's schedule_task family of cuntions > > > (kernel/context.c) - it should be straight forward to implement for FreeBSD. > > > > But entirely unnecessary, since we can already create threads in the > > kernel, as I pointed out earlier. See the kthread* family of functions. > > I know kthread ;) The differnce is just that you need an entire > thread this way - threads are eating up far too much ressources > (e.g. kernel stack) for certain types of problems. A way to just > execute some function in user context is a very nice appropeach > for lots of the smaller stuff. Some people might also remeber > NetWare's WorkToDo's that can do this stuff combines with wait queues. The linux schedule_task functions aren't all that lightweight either. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 18 13:46:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by hub.freebsd.org (Postfix) with ESMTP id F38C937B408; Sat, 18 Aug 2001 13:46:51 -0700 (PDT) (envelope-from hch@ns.caldera.de) Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f7IKkg815101; Sat, 18 Aug 2001 22:46:42 +0200 Date: Sat, 18 Aug 2001 22:46:42 +0200 From: Christoph Hellwig To: Matthew Jacob Cc: Mike Smith , Amit Shah , freebsd-arch@FreeBSD.ORG Subject: Re: threaded device drivers Message-ID: <20010818224642.A14857@caldera.de> References: <20010818220823.C8481@caldera.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Sat, Aug 18, 2001 at 01:22:07PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Aug 18, 2001 at 01:22:07PM -0700, Matthew Jacob wrote: > > The linux schedule_task functions aren't all that lightweight either. > Did you actually take a look? I bet you mean something else. The cost of schedule_task is basically allocation of an 24byte struct and one wakeup. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 18 14: 1:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 1207237B40A; Sat, 18 Aug 2001 14:01:13 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f7IL19I61311; Sat, 18 Aug 2001 14:01:09 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Sat, 18 Aug 2001 14:01:09 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Christoph Hellwig Cc: Mike Smith , Amit Shah , freebsd-arch@FreeBSD.ORG Subject: Re: threaded device drivers In-Reply-To: <20010818224642.A14857@caldera.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Oops- sorry- I got confused over what you were referring to. Apologies! For some reason I thought you were talking about linux kernel threads. The schedule_task just becomes something that keventd thread would run- it isn't available in 2.2.X, and the schedule_task functions says: * May be called from interrupt context. The scheduled function is run at some * time in the near future by the keventd kernel thread. If it can sleep, it * should be designed to do so for the minimum possible time, as it will be * stalling all other scheduled tasks. which means that it's more sensible to do your own thread anyway. On Sat, 18 Aug 2001, Christoph Hellwig wrote: > On Sat, Aug 18, 2001 at 01:22:07PM -0700, Matthew Jacob wrote: > > > > The linux schedule_task functions aren't all that lightweight either. > > > > Did you actually take a look? I bet you mean something else. > The cost of schedule_task is basically allocation of an 24byte > struct and one wakeup. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 18 14:17:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 7B6AD37B411; Sat, 18 Aug 2001 14:17:48 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f7ILM5S01713; Sat, 18 Aug 2001 14:22:05 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108182122.f7ILM5S01713@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Christoph Hellwig Cc: Mike Smith , Matthew Jacob , Amit Shah , freebsd-arch@FreeBSD.ORG Subject: Re: threaded device drivers In-reply-to: Your message of "Sat, 18 Aug 2001 22:08:23 +0200." <20010818220823.C8481@caldera.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Aug 2001 14:22:05 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > But entirely unnecessary, since we can already create threads in the > > kernel, as I pointed out earlier. See the kthread* family of functions. > > I know kthread ;) The differnce is just that you need an entire > thread this way - threads are eating up far too much ressources > (e.g. kernel stack) for certain types of problems. Er. Yeah, whatever. 8) > A way to just > execute some function in user context is a very nice appropeach > for lots of the smaller stuff. Some people might also remeber > NetWare's WorkToDo's that can do this stuff combines with wait queues. ... which is basically what taskqueue is. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 18 18: 8:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 68DD237B40C; Sat, 18 Aug 2001 18:08:48 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.4/8.11.4) id f7J18d886476; Sun, 19 Aug 2001 05:08:40 +0400 (MSD) (envelope-from ache) Date: Sun, 19 Aug 2001 05:08:38 +0400 From: "Andrey A. Chernov" To: Bruce Evans Cc: arch@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: CFR: lseek() POSIXed patch Message-ID: <20010819050838.A86450@nagual.pp.ru> References: <20010815125248.A2588@nagual.pp.ru> <20010815190108.J19482-100000@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010815190108.J19482-100000@besplex.bde.org> User-Agent: Mutt/1.3.20i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Updated variant: --- vfs_syscalls.c.old Sat Aug 11 02:14:18 2001 +++ vfs_syscalls.c Sun Aug 19 05:01:32 2001 @@ -1614,29 +1614,44 @@ register struct filedesc *fdp = p->p_fd; register struct file *fp; struct vattr vattr; - int error; + struct vnode *vp; + off_t offset; + int error, noneg; if ((u_int)SCARG(uap, fd) >= fdp->fd_nfiles || (fp = fdp->fd_ofiles[SCARG(uap, fd)]) == NULL) return (EBADF); if (fp->f_type != DTYPE_VNODE) return (ESPIPE); + vp = (struct vnode *)fp->f_data; + noneg = (vp->v_type != VCHR); + offset = SCARG(uap, offset); switch (SCARG(uap, whence)) { case L_INCR: - fp->f_offset += SCARG(uap, offset); + if (noneg && + ((offset > 0 && fp->f_offset > OFF_MAX - offset) || + (offset < 0 && fp->f_offset < OFF_MIN - offset))) + return (EOVERFLOW); + offset += fp->f_offset; break; case L_XTND: - error=VOP_GETATTR((struct vnode *)fp->f_data, &vattr, cred, p); + error = VOP_GETATTR(vp, &vattr, cred, p); if (error) return (error); - fp->f_offset = SCARG(uap, offset) + vattr.va_size; + if (noneg && + ((offset > 0 && vattr.va_size > OFF_MAX - offset) || + (offset < 0 && vattr.va_size < OFF_MIN - offset))) + return (EOVERFLOW); + offset += vattr.va_size; break; case L_SET: - fp->f_offset = SCARG(uap, offset); break; default: return (EINVAL); } + if (noneg && offset < 0) + return (EINVAL); + fp->f_offset = offset; *(off_t *)(p->p_retval) = fp->f_offset; return (0); } -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message