From owner-freebsd-arch Sun Feb 10 12:52:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.tgd.net (mail.tgd.net [209.81.25.10]) by hub.freebsd.org (Postfix) with ESMTP id DE4EA37B400 for ; Sun, 10 Feb 2002 12:52:14 -0800 (PST) Received: by mail.tgd.net (Postfix, from userid 1001) id B7BC420F0A; Sun, 10 Feb 2002 12:52:14 -0800 (PST) Date: Sun, 10 Feb 2002 12:52:14 -0800 From: Sean Chittenden To: freebsd-arch@freebsd.org Subject: Site wide daemon startup policy for ports ala ${PREFIX}/etc/(rc.conf|defaults/)... Message-ID: <20020210125214.B43813@ninja1.internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-PGP-Key: 0x1EDDFAAD X-PGP-Fingerprint: C665 A17F 9A56 286C 5CFB 1DEA 9F4F 5CEF 1EDD FAAD X-Web-Homepage: http://sean.chittenden.org/ 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 [Please direct to -hackers or -ports if more appropriate] Hypothetical situation: let's say that with SNMP I like to use syslog, which requires the -s flag to snmpd. No biggie, I can hack etc/rc.d/snmpd.sh. With many machines, however, this is a tad tiresome, esp if I don't have SNMP installed on every box. What I'd like to do is be able to use a system similar to what's in /etc with its rc.conf and defaults/rc.conf that way I could specify something akin to: snmpd_flags="-s" Just like one does with /etc/rc.conf. Quick summary (bad pseudo-code): Defaults = eval `cat ${PREFIX}/etc/defaults/*.conf` Host specific = eval `cat ${PREFIX}/etc/rc.conf` Startup script = ${PREFIX}/etc/rc.d/snmpd.sh Example implementation: A port that has configuration options would install its default parameters in ${PREFIX}/etc/defaults in a .conf file, using SNMP as an example, in ${PREFIX}/etc/defaults/snmpd.conf). When the host administrator wants to tweak a setting, such as adding the -s flag to snmpd, they tweak the settings in ${PREFIX}/etc/rc.conf. Now, when the system boots or the administrator kicks the port via ${PREFIX}/etc/snmpd.sh, it'd source a global "integrate with FreeBSD's rc/ports startup foo" function which sets the default and host specific parameters that way in snmpd.sh, you can see a nifty little line that looks something like: ${PREFIX}/sbin/snmpd ${snmpd_flags} This'd apply to other ports/apps and would require their startup scripts to be adjusted, but seems like a nice way of centralizing a lot of this configuration goo (mailman's default hostname comes to mind as another quick and easy win, same with postfix UIDs). A follow up win would also come in documenting application specific CLI tunables though ${PREFIX}/etc/defaults/${app_name}.conf. This could be a huge win for administrators. Sources of Discussion: The one bit of this that I'm a little torn about is the situation for NFS mounting /usr or /usr/local. That said, ${PREFIX}/etc/rc.conf could also be /etc/rc.conf because /etc/rc.conf shouldn't be NFS mounted. What I think would be the ideal situation would be to sourcing all three defaults in this order: defaults, ${PREFIX}/etc/rc.conf, then /etc/rc.conf. Thoughts? -sc -- Sean Chittenden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 10 13:18:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-40.dsl.lsan03.pacbell.net [64.165.226.40]) by hub.freebsd.org (Postfix) with ESMTP id 635F237BB27 for ; Sun, 10 Feb 2002 13:10:31 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 21A4C66C39; Sun, 10 Feb 2002 13:09:15 -0800 (PST) Date: Sun, 10 Feb 2002 13:09:14 -0800 From: Kris Kennaway To: Sean Chittenden Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Site wide daemon startup policy for ports ala ${PREFIX}/etc/(rc.conf|defaults/)... Message-ID: <20020210130914.B72163@xor.obsecurity.org> References: <20020210125214.B43813@ninja1.internal> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="uQr8t48UFsdbeI+V" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020210125214.B43813@ninja1.internal>; from sean@chittenden.org on Sun, Feb 10, 2002 at 12:52:14PM -0800 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 --uQr8t48UFsdbeI+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 10, 2002 at 12:52:14PM -0800, Sean Chittenden wrote: > Quick summary (bad pseudo-code): >=20 > Defaults =3D eval `cat ${PREFIX}/etc/defaults/*.conf` > Host specific =3D eval `cat ${PREFIX}/etc/rc.conf` > Startup script =3D ${PREFIX}/etc/rc.d/snmpd.sh I think this looks pretty good in outline. Can you work up a prototype? -ports might be a more appropriate list for this. Kris --uQr8t48UFsdbeI+V 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 iD8DBQE8ZuF6Wry0BWjoQKURAkbUAJ9vlgX67soorc5P3WRXi98ED/K+GQCfRcgE h+w08JulgG0ccKZaLc8uonw= =Uk5K -----END PGP SIGNATURE----- --uQr8t48UFsdbeI+V-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 10 14:27:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from voi.aagh.net (pc1-hart4-0-cust168.mid.cable.ntl.com [62.254.84.168]) by hub.freebsd.org (Postfix) with ESMTP id EDEC637B405 for ; Sun, 10 Feb 2002 14:27:25 -0800 (PST) Received: from freaky by voi.aagh.net with local (Exim 3.34 #1) id 16a2RQ-0000S9-00 for freebsd-arch@FreeBSD.ORG; Sun, 10 Feb 2002 22:27:24 +0000 Date: Sun, 10 Feb 2002 22:27:24 +0000 From: Thomas Hurst To: freebsd-arch@FreeBSD.ORG Subject: Re: Site wide daemon startup policy for ports ala ${PREFIX}/etc/(rc.conf|defaults/)... Message-ID: <20020210222724.GB1079@voi.aagh.net> Mail-Followup-To: freebsd-arch@FreeBSD.ORG References: <20020210125214.B43813@ninja1.internal> <20020210130914.B72163@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020210130914.B72163@xor.obsecurity.org> User-Agent: Mutt/1.3.27i Organization: Not much. X-Operating-System: FreeBSD/4.5-PRERELEASE (i386) X-Uptime: 10:10PM up 52 days, 6:56, 5 users, load averages: 2.00, 2.00, 2.00 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 * Kris Kennaway (kris@obsecurity.org) wrote: > On Sun, Feb 10, 2002 at 12:52:14PM -0800, Sean Chittenden wrote: > > > Quick summary (bad pseudo-code): > > > > Defaults = eval `cat ${PREFIX}/etc/defaults/*.conf` > > Host specific = eval `cat ${PREFIX}/etc/rc.conf` > > Startup script = ${PREFIX}/etc/rc.d/snmpd.sh > > I think this looks pretty good in outline. Agreed. sh library functions to do things like finding PREFIX would be nice too. Speaking of which, has any progress been made on porting the NetBSD system, and/or implimenting our own? Has anyone even tried? :) -- Thomas 'Freaky' Hurst - freaky@aagh.net - http://www.aagh.net/ - Kinkler's First Law: Responsibility always exceeds authority. Kinkler's Second Law: All the easy problems have been solved. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 10 17:22: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id 629B737B400 for ; Sun, 10 Feb 2002 17:21:59 -0800 (PST) Received: from blackbox.pacbell.net ([64.166.84.196]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GRC00FOQH4MJ0@mta6.snfc21.pbi.net> for freebsd-arch@freebsd.org; Sun, 10 Feb 2002 17:21:59 -0800 (PST) Received: (from mikem@localhost) by blackbox.pacbell.net (8.11.6/8.11.6) id g1B1Lui76229; Sun, 10 Feb 2002 17:21:56 -0800 Date: Sun, 10 Feb 2002 17:21:56 -0800 From: Mike Makonnen Subject: Re: Site wide daemon startup policy for ports ala ${PREFIX}/etc/(rc.conf|defaults/)... In-reply-to: <20020210222724.GB1079@voi.aagh.net> To: Thomas Hurst Cc: freebsd-arch@freebsd.org Message-id: <1013390516.2945.15.camel@blackbox.pacbell.net> MIME-version: 1.0 X-Mailer: Evolution/1.0.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <20020210125214.B43813@ninja1.internal> <20020210130914.B72163@xor.obsecurity.org> <20020210222724.GB1079@voi.aagh.net> X-Authentication-warning: blackbox.pacbell.net: mikem set sender to mike_makonnen@yahoo.com using -f 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 Sun, 2002-02-10 at 14:27, Thomas Hurst wrote: > > Agreed. sh library functions to do things like finding PREFIX would be > nice too. Speaking of which, has any progress been made on porting > the NetBSD system, and/or implimenting our own? Has anyone even tried? > :) > Doug Barton and Gordon Tetlow are spearheading that project. I offered to help, but I've been sidetracked lately. I'm sure they'll have something written up for the upcoming Developer's Status Report. cheers, mike makonnen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 10 21:38:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 841B837B404 for ; Sun, 10 Feb 2002 21:38:25 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g1B5cNP8026020; Mon, 11 Feb 2002 00:38:24 -0500 (EST) Date: Mon, 11 Feb 2002 00:38:23 -0500 (EST) From: Daniel Eischen To: Peter Wemm Cc: Dan Eischen , arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: <20020207063613.C1C9839F1@overcee.wemm.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 Wed, 6 Feb 2002, Peter Wemm wrote: > Daniel Eischen wrote: [ ... ] > > > > Is it OK to leave struct fpreg unchanged for now? > > To be quite honest, I think that's the right thing to do for now, until it > is clear what the "right" thing to do is. ptrace(2) isn't going to survive > KSE unscathed, so perhaps we need an enhanced ptrace interface at some point > that doesn't suffer from this kind of interface fragility. OK, done. Can I consider this reviewed and OK to be committed? Diffs with your comments incorporated are at the same place: http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs One last question, I added a new file, kern/kern_context.c, that only has about 90 or so lines in it (including copyright and includes). I wasn't sure where it fit in, kern_proc.c or kern_sig.c perhaps(?). Let me know if it should be moved to one of these files or another existing file. Otherwise, I'll just leave it in kern_context.c. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 11 2:58: 9 2002 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 C3E0C37B41A for ; Mon, 11 Feb 2002 02:58:05 -0800 (PST) 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 VAA24656; Mon, 11 Feb 2002 21:57:49 +1100 Date: Mon, 11 Feb 2002 22:00:39 +1100 (EST) From: Bruce Evans X-X-Sender: To: Daniel Eischen Cc: Peter Wemm , Dan Eischen , Subject: Re: getsetcontext system call In-Reply-To: Message-ID: <20020211210412.X308-100000@gamplex.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 Mon, 11 Feb 2002, Daniel Eischen wrote: > On Wed, 6 Feb 2002, Peter Wemm wrote: > > Daniel Eischen wrote: > [ ... ] > > > > > > Is it OK to leave struct fpreg unchanged for now? > > > > To be quite honest, I think that's the right thing to do for now, until it > > is clear what the "right" thing to do is. ptrace(2) isn't going to survive > > KSE unscathed, so perhaps we need an enhanced ptrace interface at some point > > that doesn't suffer from this kind of interface fragility. > > OK, done. Can I consider this reviewed and OK to be committed? Diffs > with your comments incorporated are at the same place: > > http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs > http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs I noticed a few minor problems with it, but haven't completely reviewed it. From your original mail: ! I also changed the alpha a bit. When delivering signals, it ! dropped the FPU if it was currently owned. This wasn't done ! on i386, and I didn't see a reason why it would need to be done ! for alpha. For i386, signal deliver now includes the FPU ! context. Well, signals handlers should get a clean FPU state, and you don't want spend much time looking at the current state to see if it is clean. Saving the state into the ucontext and initializing a clean state without looking is probably best. For i386's without fxsr, saving the state loads a new, clean state into the FPU whether you want it to or not, so it would be best to pass that state to the signal handler and not put it in the pcb, even though signal handlers probably won't use it (saving it to the pcb would usually be a waste of time, since the state will usually be restored from the ucontext and not from the pcb). For i386's with fxsr, saving the state doesn't change the state in the FPU, so initializing the clean state in the pcb only is probably better (forget the state in the FPU). For i386's with or without fxsr, if the signal handler returns it is difficult to tell if the state being "restored" is already in the FPU, since the signal handler may have modified the ucontext. Copying the ucontext to the pcb and forgetting the state in the FPU seems best in both cases. get_fpcontext() and set_fpcontext() don't have the right semantics for signal handling. They try too hard to keep the state in the FPU if it is already there, but in sendsig() you never want it (the old state) there. I just noticed a not so minor problem: get_fpcontext() on i386's only works for the fxsr case, since it assumes that the state is is still in the FPU after fpusave(). fpusave() and npxsave() probably shouldn't exist, since they mainly obfuscate the critical differences between fnsave() and fxsave(). > One last question, I added a new file, kern/kern_context.c, that only > has about 90 or so lines in it (including copyright and includes). I > wasn't sure where it fit in, kern_proc.c or kern_sig.c perhaps(?). > Let me know if it should be moved to one of these files or another > existing file. Otherwise, I'll just leave it in kern_context.c. I can't think of a better place than the new file. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 11 5:13:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 9EC7237B42A for ; Mon, 11 Feb 2002 05:13:13 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g1BDD9lw002559; Mon, 11 Feb 2002 08:13:10 -0500 (EST) Date: Mon, 11 Feb 2002 08:13:09 -0500 (EST) From: Daniel Eischen To: Bruce Evans Cc: Peter Wemm , Dan Eischen , arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: <20020211210412.X308-100000@gamplex.bde.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 Mon, 11 Feb 2002, Bruce Evans wrote: > On Mon, 11 Feb 2002, Daniel Eischen wrote: > > > On Wed, 6 Feb 2002, Peter Wemm wrote: > > > Daniel Eischen wrote: > > [ ... ] > > > > > > > > Is it OK to leave struct fpreg unchanged for now? > > > > > > To be quite honest, I think that's the right thing to do for now, until it > > > is clear what the "right" thing to do is. ptrace(2) isn't going to survive > > > KSE unscathed, so perhaps we need an enhanced ptrace interface at some point > > > that doesn't suffer from this kind of interface fragility. > > > > OK, done. Can I consider this reviewed and OK to be committed? Diffs > > with your comments incorporated are at the same place: > > > > http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs > > http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs > > I noticed a few minor problems with it, but haven't completely reviewed it. > > >From your original mail: > > ! I also changed the alpha a bit. When delivering signals, it > ! dropped the FPU if it was currently owned. This wasn't done > ! on i386, and I didn't see a reason why it would need to be done > ! for alpha. For i386, signal deliver now includes the FPU > ! context. > > Well, signals handlers should get a clean FPU state, and you don't > want spend much time looking at the current state to see if it is > clean. Saving the state into the ucontext and initializing a clean > state without looking is probably best. For i386's without fxsr, > saving the state loads a new, clean state into the FPU whether you > want it to or not, so it would be best to pass that state to the signal > handler and not put it in the pcb, even though signal handlers probably > won't use it (saving it to the pcb would usually be a waste of time, > since the state will usually be restored from the ucontext and not > from the pcb). For i386's with fxsr, saving the state doesn't change > the state in the FPU, so initializing the clean state in the pcb only > is probably better (forget the state in the FPU). But if you already own the FPU, doing anything in the PCB is a waste of time. You're not going to get a trap to reload the state from the PCB, and the next FPU context switch will dump the current FPU state to the PCB (overwriting the clean state). > For i386's with or > without fxsr, if the signal handler returns it is difficult to tell > if the state being "restored" is already in the FPU, since the signal > handler may have modified the ucontext. Copying the ucontext to the > pcb and forgetting the state in the FPU seems best in both cases. But again, if you know that the thread owns the FPU, saving it to the PCB doesn't do anything. Unless you want to drop FPU ownership everytime you deliver a signal as alpha does. > get_fpcontext() and set_fpcontext() don't have the right semantics for > signal handling. They try too hard to keep the state in the FPU if it > is already there, but in sendsig() you never want it (the old state) > there. OK, so we want a clean FPU state whenever signals get delivered, saving the old FPU state in the ucontext. Do you want to drop FPU ownership and initialize the clean state in the PCB? And how do you get a clean state for with and without fxsr? Does fninit do it for both? If we want to initialize the PCB with a clean state, where do we copy it from? > I just noticed a not so minor problem: get_fpcontext() on i386's only > works for the fxsr case, since it assumes that the state is is still > in the FPU after fpusave(). fpusave() and npxsave() probably shouldn't > exist, since they mainly obfuscate the critical differences between > fnsave() and fxsave(). I'll have to take a look. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 11 10:51:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from relay.gnf.org (relay.gnf.org [208.44.31.36]) by hub.freebsd.org (Postfix) with ESMTP id 3EC0A37B436 for ; Mon, 11 Feb 2002 10:51:07 -0800 (PST) Received: from mail.gnf.org (smtp.gnf.org [10.0.0.11]) by relay.gnf.org (8.11.6/8.11.6) with ESMTP id g1BIp0w24589; Mon, 11 Feb 2002 10:51:04 -0800 Received: by mail.gnf.org (Postfix, from userid 888) id EE50411E508; Mon, 11 Feb 2002 10:48:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.gnf.org (Postfix) with ESMTP id EAE0A11A572; Mon, 11 Feb 2002 10:48:31 -0800 (PST) Date: Mon, 11 Feb 2002 10:48:31 -0800 (PST) From: Gordon Tetlow To: Mike Makonnen Cc: Thomas Hurst , Subject: Re: Site wide daemon startup policy for ports ala ${PREFIX}/etc/(rc.conf|defaults/)... In-Reply-To: <1013390516.2945.15.camel@blackbox.pacbell.net> 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 Sun, 10 Feb 2002, Mike Makonnen wrote: > Doug Barton and Gordon Tetlow are spearheading that project. I offered > to help, but I've been sidetracked lately. I'm sure they'll have > something written up for the upcoming Developer's Status Report. I didn't submit anything this time and I don't know about Doug. I've been very busy at work and only had a cursory chance to look at the rc.d stuff. I'm hoping I can pick it up a bit more, but with work as it is, it might not be possible for another month or so. -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 3:55:19 2002 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 CD9AA37B416 for ; Tue, 12 Feb 2002 03:55:13 -0800 (PST) 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 WAA20662; Tue, 12 Feb 2002 22:17:47 +1100 Date: Tue, 12 Feb 2002 22:20:40 +1100 (EST) From: Bruce Evans X-X-Sender: To: Daniel Eischen Cc: Peter Wemm , Dan Eischen , Subject: Re: getsetcontext system call In-Reply-To: Message-ID: <20020212215001.Q3960-100000@gamplex.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 Mon, 11 Feb 2002, Daniel Eischen wrote: > On Mon, 11 Feb 2002, Bruce Evans wrote: > > Well, signals handlers should get a clean FPU state, and you don't > > want spend much time looking at the current state to see if it is > > clean. Saving the state into the ucontext and initializing a clean > > state without looking is probably best. For i386's without fxsr, > > saving the state loads a new, clean state into the FPU whether you > > want it to or not, so it would be best to pass that state to the signal > > handler and not put it in the pcb, even though signal handlers probably > > won't use it (saving it to the pcb would usually be a waste of time, > > since the state will usually be restored from the ucontext and not > > from the pcb). For i386's with fxsr, saving the state doesn't change > > the state in the FPU, so initializing the clean state in the pcb only > > is probably better (forget the state in the FPU). > > But if you already own the FPU, doing anything in the PCB is a > waste of time. You're not going to get a trap to reload the > state from the PCB, and the next FPU context switch will dump the > current FPU state to the PCB (overwriting the clean state). You don't really own it, because the signal handler needs a different context. That context is probably best provided by putting it in the PCB, since the signal handler is unlikely to actually use it. (The optimal implementation of it is probably to put only a single bit in the PCB -- a flag that says that the state needs initialization.) This is all for the fxsr case -- in the !fxsr case, fnsave initializes the FPU to a clean state (too clean; we would have to add an fldcw to get the default control word). Since the signal handler rarely uses this state, it might be best to use the handling for the fxsr case in all cases. > > For i386's with or > > without fxsr, if the signal handler returns it is difficult to tell > > if the state being "restored" is already in the FPU, since the signal > > handler may have modified the ucontext. Copying the ucontext to the > > pcb and forgetting the state in the FPU seems best in both cases. > > But again, if you know that the thread owns the FPU, saving it to > the PCB doesn't do anything. Unless you want to drop FPU ownership > everytime you deliver a signal as alpha does. I think I do want that. It is simplest and close to optimal too. There is no use keeping it, since we will have to reload it when (if) the signal handler returns. In sendsig(), we don't save the state in the PCB; we just save/copy it in/to the ucontext and copy a clean state to the PCB (or set a bit that says that the state needs cleaning) > > get_fpcontext() and set_fpcontext() don't have the right semantics for > > signal handling. They try too hard to keep the state in the FPU if it > > is already there, but in sendsig() you never want it (the old state) > > there. > > OK, so we want a clean FPU state whenever signals get delivered, > saving the old FPU state in the ucontext. Do you want to drop > FPU ownership and initialize the clean state in the PCB? And > how do you get a clean state for with and without fxsr? Does > fninit do it for both? If we want to initialize the PCB with a > clean state, where do we copy it from? I think fninit does enough (not sure). We can either copy the clean state from a prepared clean state, or us fninit or whatever in npxdna() and put only the needs-cleaning bit in the PCB. Use a copy, or fninit + fldcw, or just npxinit() to begin with. We can optimize it later. Hmm, npxinit() is heavyweight. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 11:34:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from antipater.hosting.pacbell.net (antipater.hosting.pacbell.net [216.100.99.13]) by hub.freebsd.org (Postfix) with ESMTP id C2F8A37B433 for ; Tue, 12 Feb 2002 11:33:41 -0800 (PST) Received: from misha1 (adsl-64-172-38-74.dsl.snfc21.pacbell.net [64.172.38.74]) by antipater.hosting.pacbell.net id OAA13683; Tue, 12 Feb 2002 14:32:14 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <009401c1b3f9$1ffe6980$b210a8c0@netscreen5> Reply-To: "mike varga" From: "mike varga" To: Subject: dmamap Date: Tue, 12 Feb 2002 11:02:44 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01C1B3B4.CC16DC60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 This is a multi-part message in MIME format. ------=_NextPart_000_008F_01C1B3B4.CC16DC60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am modifying a driver to=20 map user addresses into kernel space to be used by DMA. Is there a facility like what exists within Linux that will allow me to map and wire user pages? Linux: alloc_kiovec(), map_user_kiobuf(), kmap(); I did find these, are they appropriate? FreeBSD: vm_map_create(), vm_map_user_pagable(); Also, is there an example or documentation that exists for what I am trying. ------=_NextPart_000_008F_01C1B3B4.CC16DC60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am modifying a driver to =
map user addresses into kernel = space
to be used by=20 DMA.
 
Is there a facility like
what exists within Linux
that will allow me to map
and wire user pages?
 
Linux: alloc_kiovec(), = map_user_kiobuf(),=20 kmap();
 
I did find these, are they=20 appropriate?
 
FreeBSD: vm_map_create(),=20 vm_map_user_pagable();
 
Also, is there an example = or
documentation that exists = for
what I am trying.
 
 
 
 
 
 
------=_NextPart_000_008F_01C1B3B4.CC16DC60-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 13:48:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 11B3A37B404; Tue, 12 Feb 2002 13:48:34 -0800 (PST) Received: by sneakerz.org (Postfix, from userid 1023) id 5237A5D006; Tue, 12 Feb 2002 15:48:28 -0600 (CST) Date: Tue, 12 Feb 2002 15:48:28 -0600 From: Maxime Henrion To: freebsd-arch@FreeBSD.org Cc: brooks@freebsd.org Subject: Patches to if_loop + the interface cloning framework Message-ID: <20020212154828.A25374@sneakerz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i 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 all, I recently noticed that the if_loop interface was using a loader tunable (net.nloop), which is a sysctl later, to allow having more than one loopback interface. Since Brooks Davis recently gave FreeBSD a more generic interface cloning framework, I started to hack if_loop to use it instead. The result of this work is available at : http://www.sneakerz.org/~mux/loop.diff This patch allows the loopback interfaces to be managed the same way as other cloning interfaces (gif, vlan...), that is, with ``ifconfig loX {create|destroy}''. There is however one problem with this patch, as stated in the added XXX comment : /* * Prevent lo0 from being destroyed * XXX Since the clone_destroy() function * is void, there is no way to return * an error back to the upper layer. */ The reason why lo0 can't be destroyed is that there is a global struct ifnet *loif pointer which points to it used by some code in the kernel. Destroying this interface would cause panics if this pointer is accessed later. We thus need a way to report this error to the upper layer. I slightly modified the interface cloning framework to this purpose, changing the prototype of foo_clone_destroy() to be a function returning an int. The patch containing this change plus the if_loop change is available at : http://www.sneakerz.org/~mux/net.diff Of course, any reviews or comments would be greatly appreciated. Thanks, Maxime Henrion Note: the if_loop part of the changes also include some more minor modifications : the removing of a few __P() macros, and the replacement of all "lo" by a LONAME macro. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 14:39:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id C10A337B41D for ; Tue, 12 Feb 2002 14:39:19 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g1CMd9V14667; Tue, 12 Feb 2002 14:39:09 -0800 Date: Tue, 12 Feb 2002 14:39:09 -0800 From: Brooks Davis To: Maxime Henrion Cc: freebsd-arch@FreeBSD.org Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020212143909.B24768@Odin.AC.HMC.Edu> References: <20020212154828.A25374@sneakerz.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="bCsyhTFzCvuiizWE" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020212154828.A25374@sneakerz.org>; from mux@sneakerz.org on Tue, Feb 12, 2002 at 03:48:28PM -0600 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 --bCsyhTFzCvuiizWE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 12, 2002 at 03:48:28PM -0600, Maxime Henrion wrote: > The reason why lo0 can't be destroyed is that there is a global struct > ifnet *loif pointer which points to it used by some code in the kernel. > Destroying this interface would cause panics if this pointer is accessed > later. We thus need a way to report this error to the upper layer. I > slightly modified the interface cloning framework to this purpose, > changing the prototype of foo_clone_destroy() to be a function returning > an int. The patch containing this change plus the if_loop change is > available at : > http://www.sneakerz.org/~mux/net.diff >=20 > Of course, any reviews or comments would be greatly appreciated. By and large it looks good so far. I've got a couple minor issues though. First, I think we should at least KASSERT and probably just panic if lo_clone_create() failes in loop_modevent since that causes the same problem as deleting lo0. Also, if there are users of the net.nloop out there, we may want to figure out a way to support them in stable. It's always possiable that there aren't any users of net.nloop and thus we don't need to worry, but I'd prefer to ask before tossing support in stable. I've got no qualms about ripping in out in current. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --bCsyhTFzCvuiizWE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8aZmMXY6L6fI4GtQRAr/dAKDAw2regbb5hAKFvKPIVljJkX9qlwCfWF8n 02wij78wVNgiivL31WCGKLQ= =Vo+w -----END PGP SIGNATURE----- --bCsyhTFzCvuiizWE-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 14:56: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 24FEE37B416 for ; Tue, 12 Feb 2002 14:55:54 -0800 (PST) Received: by sneakerz.org (Postfix, from userid 1023) id 798155D006; Tue, 12 Feb 2002 16:55:44 -0600 (CST) Date: Tue, 12 Feb 2002 16:55:44 -0600 From: Maxime Henrion To: freebsd-arch@freebsd.org Cc: Brooks Davis Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020212165544.B25374@sneakerz.org> References: <20020212154828.A25374@sneakerz.org> <20020212143909.B24768@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020212143909.B24768@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Tue, Feb 12, 2002 at 02:39:09PM -0800 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 Brooks Davis (brooks@one-eyed-alien.net) wrote: > By and large it looks good so far. I've got a couple minor issues > though. First, I think we should at least KASSERT and probably > just panic if lo_clone_create() failes in loop_modevent since that > causes the same problem as deleting lo0. I see your concern but this raises some other questions : if it is so bad that we have to panic if we're not be able to create the lo0 interface, then why do we have if_loop available as a module at all ? I'm all for having a KASSERT() or a panic() in that case, but I'd rather see it in a SYSINIT after having removed KLD support. > Also, if there are users of > the net.nloop out there, we may want to figure out a way to support them > in stable. It's always possiable that there aren't any users of > net.nloop and thus we don't need to worry, but I'd prefer to ask before > tossing support in stable. I've got no qualms about ripping in out in > current. Yes, I think it would be good to support net.nloop again in -STABLE. I can write another patch for this. Thanks, Maxime Henrion To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 15:39: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id C7E5037B400 for ; Tue, 12 Feb 2002 15:38:56 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g1CNa9324735; Tue, 12 Feb 2002 15:36:09 -0800 Date: Tue, 12 Feb 2002 15:36:09 -0800 From: Brooks Davis To: Maxime Henrion Cc: freebsd-arch@freebsd.org, Brooks Davis Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020212153609.D24768@Odin.AC.HMC.Edu> References: <20020212154828.A25374@sneakerz.org> <20020212143909.B24768@Odin.AC.HMC.Edu> <20020212165544.B25374@sneakerz.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ylS2wUBXLOxYXZFQ" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020212165544.B25374@sneakerz.org>; from mux@sneakerz.org on Tue, Feb 12, 2002 at 04:55:44PM -0600 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 --ylS2wUBXLOxYXZFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 12, 2002 at 04:55:44PM -0600, Maxime Henrion wrote: > Brooks Davis (brooks@one-eyed-alien.net) wrote: > > By and large it looks good so far. I've got a couple minor issues > > though. First, I think we should at least KASSERT and probably > > just panic if lo_clone_create() failes in loop_modevent since that > > causes the same problem as deleting lo0. >=20 > I see your concern but this raises some other questions : if it is so > bad that we have to panic if we're not be able to create the lo0 interfac= e, > then why do we have if_loop available as a module at all ? I'm all for > having a KASSERT() or a panic() in that case, but I'd rather see it in a > SYSINIT after having removed KLD support. You can't make if_loop a module because the kernel will have an unresolved symbol (loif) if you do at this point. The main reasion I suggested a panic was that, you'd know immediatly that you didn't have a loopback device. It looks to me like you'll quickly derefrence a NULL pointer in one of the IPv6 SYSINITs if you don't have a valid loif. At the very least there needs to be a printf here saying allocation failed. I'd argue that there's pretty much no chance of recovery if it does because that's the result of failing to malloc a pretty minimal amount of memory and thus that a panic is the right thing to do, but I guess I don't care that much. Now that I look at the code again, locreate() does no error checking what so ever which is probably a bigger issue (and not your fault). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ylS2wUBXLOxYXZFQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8aabpXY6L6fI4GtQRAmzQAJ9MazAPB6BdOC43ujxSH23PHygUvgCeIlcM y+vxvcd9cQO5peZVnXwz5aA= =VzT/ -----END PGP SIGNATURE----- --ylS2wUBXLOxYXZFQ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 15:45:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id F01D037B486 for ; Tue, 12 Feb 2002 15:45:04 -0800 (PST) Received: by sneakerz.org (Postfix, from userid 1023) id D53645D006; Tue, 12 Feb 2002 17:44:53 -0600 (CST) Date: Tue, 12 Feb 2002 17:44:53 -0600 From: Maxime Henrion To: freebsd-arch@freebsd.org Cc: Brooks Davis Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020212174453.C25374@sneakerz.org> References: <20020212154828.A25374@sneakerz.org> <20020212143909.B24768@Odin.AC.HMC.Edu> <20020212165544.B25374@sneakerz.org> <20020212153609.D24768@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020212153609.D24768@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Tue, Feb 12, 2002 at 03:36:09PM -0800 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 Brooks Davis (brooks@one-eyed-alien.net) wrote: > On Tue, Feb 12, 2002 at 04:55:44PM -0600, Maxime Henrion wrote: > > Brooks Davis (brooks@one-eyed-alien.net) wrote: > > > By and large it looks good so far. I've got a couple minor issues > > > though. First, I think we should at least KASSERT and probably > > > just panic if lo_clone_create() failes in loop_modevent since that > > > causes the same problem as deleting lo0. > > > > I see your concern but this raises some other questions : if it is so > > bad that we have to panic if we're not be able to create the lo0 interface, > > then why do we have if_loop available as a module at all ? I'm all for > > having a KASSERT() or a panic() in that case, but I'd rather see it in a > > SYSINIT after having removed KLD support. > > You can't make if_loop a module because the kernel will have an unresolved > symbol (loif) if you do at this point. The main reasion I suggested a > panic was that, you'd know immediatly that you didn't have a loopback > device. It looks to me like you'll quickly derefrence a NULL pointer in > one of the IPv6 SYSINITs if you don't have a valid loif. OK, I wasn't aware of this. > At the very least there needs to be a printf here saying allocation > failed. I'd argue that there's pretty much no chance of recovery if it > does because that's the result of failing to malloc a pretty minimal > amount of memory and thus that a panic is the right thing to do, but > I guess I don't care that much. Now that I look at the code again, > locreate() does no error checking what so ever which is probably a > bigger issue (and not your fault). I've updated the patch at the same location, adding a panic() in case the creation of lo0 fails. I'll be interested in removing the KLD stuff from this file since it's not working anyway, and adds some error checking, but that will be a bit later ;-) Thanks, Maxime Henrion To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 15:56:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id D598D37B416 for ; Tue, 12 Feb 2002 15:56:47 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g1CNukF28092; Tue, 12 Feb 2002 15:56:46 -0800 Date: Tue, 12 Feb 2002 15:56:46 -0800 From: Brooks Davis To: Maxime Henrion Cc: freebsd-arch@freebsd.org, Brooks Davis Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020212155646.A26408@Odin.AC.HMC.Edu> References: <20020212154828.A25374@sneakerz.org> <20020212143909.B24768@Odin.AC.HMC.Edu> <20020212165544.B25374@sneakerz.org> <20020212153609.D24768@Odin.AC.HMC.Edu> <20020212174453.C25374@sneakerz.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020212174453.C25374@sneakerz.org>; from mux@sneakerz.org on Tue, Feb 12, 2002 at 05:44:53PM -0600 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 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 12, 2002 at 05:44:53PM -0600, Maxime Henrion wrote: >=20 > I've updated the patch at the same location, adding a panic() in case > the creation of lo0 fails. I'll be interested in removing the KLD > stuff from this file since it's not working anyway, and adds some error > checking, but that will be a bit later ;-) Looks good though error checking would be nice. ;-) I'm not convinced that removing the module support is a good idea. I'd much rather move in the other direction in general. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8aau9XY6L6fI4GtQRAogAAJ9AGxFd1EJP44SBgddPOzBwJKmzlgCfe+iE 0tJ6mEgo18/eIS9KWxACsLI= =UzzA -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 16: 3:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 6DA5037B402 for ; Tue, 12 Feb 2002 16:03:43 -0800 (PST) Received: by sneakerz.org (Postfix, from userid 1023) id B4D075D006; Tue, 12 Feb 2002 18:03:37 -0600 (CST) Date: Tue, 12 Feb 2002 18:03:37 -0600 From: Maxime Henrion To: freebsd-arch@freebsd.org Cc: Brooks Davis Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020212180337.D25374@sneakerz.org> References: <20020212154828.A25374@sneakerz.org> <20020212143909.B24768@Odin.AC.HMC.Edu> <20020212165544.B25374@sneakerz.org> <20020212153609.D24768@Odin.AC.HMC.Edu> <20020212174453.C25374@sneakerz.org> <20020212155646.A26408@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020212155646.A26408@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Tue, Feb 12, 2002 at 03:56:46PM -0800 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 Brooks Davis (brooks@one-eyed-alien.net) wrote: > On Tue, Feb 12, 2002 at 05:44:53PM -0600, Maxime Henrion wrote: > > > > I've updated the patch at the same location, adding a panic() in case > > the creation of lo0 fails. I'll be interested in removing the KLD > > stuff from this file since it's not working anyway, and adds some error > > checking, but that will be a bit later ;-) > > Looks good though error checking would be nice. ;-) Actually, after taking a closer look at it, there is no error checking that can be done in locreate(). It calls if_attach() and bpfattach() which are both void functions and calls malloc() with M_WAITOK. Were you talking about something else ? > I'm not convinced > that removing the module support is a good idea. I'd much rather move > in the other direction in general. What would it be useful to, if the kernel can't link without it ? Thanks, Maxime Henrion To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 16:11:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 1571337B400 for ; Tue, 12 Feb 2002 16:11:30 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g1D0BT530690; Tue, 12 Feb 2002 16:11:29 -0800 Date: Tue, 12 Feb 2002 16:11:29 -0800 From: Brooks Davis To: Maxime Henrion Cc: freebsd-arch@freebsd.org, Brooks Davis Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020212161129.A29154@Odin.AC.HMC.Edu> References: <20020212154828.A25374@sneakerz.org> <20020212143909.B24768@Odin.AC.HMC.Edu> <20020212165544.B25374@sneakerz.org> <20020212153609.D24768@Odin.AC.HMC.Edu> <20020212174453.C25374@sneakerz.org> <20020212155646.A26408@Odin.AC.HMC.Edu> <20020212180337.D25374@sneakerz.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020212180337.D25374@sneakerz.org>; from mux@sneakerz.org on Tue, Feb 12, 2002 at 06:03:37PM -0600 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 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 12, 2002 at 06:03:37PM -0600, Maxime Henrion wrote: > Actually, after taking a closer look at it, there is no error checking > that can be done in locreate(). It calls if_attach() and bpfattach() > which are both void functions and calls malloc() with M_WAITOK. Were > you talking about something else ? Oops, you are correct. For some reasion I though M_WAITOK sometimes (rairly) failed, but according to the manpage I'm misremembering that flamewar. In that case, your origional code was correct in that the only way it can fail is if it already exists which isn't really a problem (though it's probably worth a KASSERT since it would represent a bug.) > What would it be useful to, if the kernel can't link without it ? The linking problem would be a fairly trivial fix. You would just have to move the definition elsewhere like I did with the external interfaces to faith(4). The underlying "specialness" of the loopback is another issue though and I'm not sure what the answer is. That doesn't mean there isn't one though and I don't see any reasion why we should go out of our way to remove support for the loopback device as a module. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8aa8wXY6L6fI4GtQRAlq+AKCZs/EtVNW9bzWNXS/1QRtyrwQEUQCg2NEH AEWXbw2aHrLlSYdWXQ2FORI= =koUv -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 16:19:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id B517F37B402 for ; Tue, 12 Feb 2002 16:19:39 -0800 (PST) Received: by sneakerz.org (Postfix, from userid 1023) id 4C0695D006; Tue, 12 Feb 2002 18:19:39 -0600 (CST) Date: Tue, 12 Feb 2002 18:19:39 -0600 From: Maxime Henrion To: freebsd-arch@freebsd.org Cc: Brooks Davis Subject: Re: Patches to if_loop + the interface cloning framework Message-ID: <20020212181939.E25374@sneakerz.org> References: <20020212154828.A25374@sneakerz.org> <20020212143909.B24768@Odin.AC.HMC.Edu> <20020212165544.B25374@sneakerz.org> <20020212153609.D24768@Odin.AC.HMC.Edu> <20020212174453.C25374@sneakerz.org> <20020212155646.A26408@Odin.AC.HMC.Edu> <20020212180337.D25374@sneakerz.org> <20020212161129.A29154@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020212161129.A29154@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Tue, Feb 12, 2002 at 04:11:29PM -0800 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 Brooks Davis (brooks@one-eyed-alien.net) wrote: > On Tue, Feb 12, 2002 at 06:03:37PM -0600, Maxime Henrion wrote: > > Actually, after taking a closer look at it, there is no error checking > > that can be done in locreate(). It calls if_attach() and bpfattach() > > which are both void functions and calls malloc() with M_WAITOK. Were > > you talking about something else ? > > Oops, you are correct. For some reasion I though M_WAITOK sometimes > (rairly) failed, but according to the manpage I'm misremembering that > flamewar. In that case, your origional code was correct in that the > only way it can fail is if it already exists which isn't really a problem > (though it's probably worth a KASSERT since it would represent a bug.) > > > What would it be useful to, if the kernel can't link without it ? > > The linking problem would be a fairly trivial fix. You would just have > to move the definition elsewhere like I did with the external interfaces > to faith(4). The underlying "specialness" of the loopback is another > issue though and I'm not sure what the answer is. That doesn't mean > there isn't one though and I don't see any reasion why we should go out > of our way to remove support for the loopback device as a module. Got you on that one. :-) I uploaded the final patch (with a KASSERT) still at the same location, http://www.sneakerz.org/~mux/net.diff. Cheers, Maxime Henrion To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 17:14:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from antipater.hosting.pacbell.net (antipater.hosting.pacbell.net [216.100.99.13]) by hub.freebsd.org (Postfix) with ESMTP id 7CD9137B405 for ; Tue, 12 Feb 2002 17:14:17 -0800 (PST) Received: from misha1 (adsl-64-172-38-74.dsl.snfc21.pacbell.net [64.172.38.74]) by antipater.hosting.pacbell.net id UAA04865; Tue, 12 Feb 2002 20:14:11 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <00d401c1b428$e4929df0$b210a8c0@netscreen5> Reply-To: "mike varga" From: "mike varga" To: Subject: bus_dma_load_uio() function Date: Tue, 12 Feb 2002 16:51:25 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D1_01C1B3E5.8206C910" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 This is a multi-part message in MIME format. ------=_NextPart_000_00D1_01C1B3E5.8206C910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In FreeBSD does there exist a similar function or a combination of functions to do the same thing as NetBSD's=20 bus_dmamap_load_uio()? This function is a variation of the bus_dmamap_load(), which maps buffers pointed to by uio for=20 DMA transfers. The value of=20 uio->uio_segflg determins if the buffer is in user or kernel space. ------=_NextPart_000_00D1_01C1B3E5.8206C910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In FreeBSD does there exist a similar=20 function
or a combination of functions = to=20 do
the same thing as NetBSD's
bus_dmamap_load_uio()?
 
This function is a variation = of
the bus_dmamap_load(), which = maps
buffers pointed to by uio for =
DMA transfers. The value of =
uio->uio_segflg determins if = the
buffer is in user or kernel = space.
 
------=_NextPart_000_00D1_01C1B3E5.8206C910-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 17:54:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from philotas.hosting.pacbell.net (philotas.hosting.pacbell.net [216.100.99.24]) by hub.freebsd.org (Postfix) with ESMTP id 910D737B419 for ; Tue, 12 Feb 2002 17:54:07 -0800 (PST) Received: from misha1 (adsl-64-172-38-74.dsl.snfc21.pacbell.net [64.172.38.74]) by philotas.hosting.pacbell.net id UAA02654; Tue, 12 Feb 2002 20:54:06 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <000701c1b42e$7835eda0$b210a8c0@netscreen5> Reply-To: "mike varga" From: "mike varga" To: "Steve Kargl" , References: <00d401c1b428$e4929df0$b210a8c0@netscreen5> <20020212172445.A85182@troutmask.apl.washington.edu> Subject: Re: bus_dma_load_uio() function Date: Tue, 12 Feb 2002 17:33:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Yes I did, but thank you for replying. My question essentially boils down to,"How do you map and lock user pages (buffers) for use in a driver that wants to do a DMA directly from/to them. It removes unnecessary copies. ----- Original Message ----- From: "Steve Kargl" To: "mike varga" Sent: Tuesday, February 12, 2002 5:24 PM Subject: Re: bus_dma_load_uio() function > On Tue, Feb 12, 2002 at 04:51:25PM -0800, mike varga wrote: > > In FreeBSD does there exist a similar function > > or a combination of functions to do > > the same thing as NetBSD's > > bus_dmamap_load_uio()? > > > > This function is a variation of > > the bus_dmamap_load(), which maps > > buffers pointed to by uio for > > DMA transfers. The value of > > uio->uio_segflg determins if the > > buffer is in user or kernel space. > > > > I assume you didn't try the obvious. > > find /usr/include -type file | xargs grep _dma | more > > Gives among others things /usr/include/machine/bus_at386.h > to look over. > > -- > Steve > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 12 18:36: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from b.mx.canon.com.au (bexfield.research.canon.com.au [203.12.172.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E2A237B405 for ; Tue, 12 Feb 2002 18:36:00 -0800 (PST) Received: from bellmann.research.canon.com.au (kwanon.research.canon.com.au [203.12.172.254]) by b.mx.canon.com.au (Postfix) with ESMTP id 095171AC721; Wed, 13 Feb 2002 02:35:59 +0000 (GMT) Received: from blow.research.canon.com.au (blow.research.canon.com.au [10.8.1.4]) by bellmann.research.canon.com.au (Postfix) with ESMTP id D6A4D8B37; Wed, 13 Feb 2002 13:13:06 +1100 (EST) Received: by blow.research.canon.com.au (Postfix, from userid 683) id 17C3732711; Wed, 13 Feb 2002 13:35:14 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by blow.research.canon.com.au (Postfix) with ESMTP id 060A2326C5; Wed, 13 Feb 2002 13:35:14 +1100 (EST) Date: Wed, 13 Feb 2002 13:35:13 +1100 (EST) From: Iain Templeton To: mike varga Cc: freebsd-arch@freebsd.org Subject: Re: bus_dma_load_uio() function In-Reply-To: <000701c1b42e$7835eda0$b210a8c0@netscreen5> 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 Tue, 12 Feb 2002, mike varga wrote: > Yes I did, but thank you > for replying. > > My question essentially > boils down to,"How do you > map and lock user pages (buffers) > for use in a driver that wants > to do a DMA directly > from/to them. > > It removes unnecessary > copies. > We use vm_map_user_pageable() for our device driver, seems to work. We get the physical address as part of the callback for bus_dmamap_load(). We manage the data in the uio struct ourselves, as the data has some extra header information that needs to be processed. Iain To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 13 1:46:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 1336E37B417 for ; Wed, 13 Feb 2002 01:46:21 -0800 (PST) Received: from pool0136.cvx21-bradley.dialup.earthlink.net ([209.179.192.136] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16avzS-0000MW-00; Wed, 13 Feb 2002 01:46:14 -0800 Message-ID: <3C6A35DC.F03DC26A@mindspring.com> Date: Wed, 13 Feb 2002 01:46:04 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mike varga Cc: Steve Kargl , freebsd-arch@freebsd.org Subject: Re: bus_dma_load_uio() function References: <00d401c1b428$e4929df0$b210a8c0@netscreen5> <20020212172445.A85182@troutmask.apl.washington.edu> <000701c1b42e$7835eda0$b210a8c0@netscreen5> 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 mike varga wrote: > My question essentially > boils down to,"How do you > map and lock user pages (buffers) > for use in a driver that wants > to do a DMA directly > from/to them. > > It removes unnecessary > copies. Hi, Mike. Normally, this type of copy elimination is done, not by taking user pages and making them available to the driver, but by taking driver pages, and making them available to the user space program. There are a lot of ways to do this, but it normally depends on how you intend to do the accesses. If your driver has a device node, the simplest way is to allocate a memory region when the driver is instanced, and then use mmap() on the device itself to map the pages into the user space program. This has the usually desirable side effect of making the memory access controls equal to the driver enforced access controls on the open. There are a number of drivers, such as the bktr and other capture cards, as well as the linear frame buffer devices. See also /dev/agpgart. Another alternative is to use System V shared memory, which is implemented as a KVA space allocation which gets mapped into the user process address space as a result of the attach. This memory is wired down, and it also will not move out from under you while you are using it. You can use this approach by making a single call to the driver to identify the shared memory segment to it, and then use relative addressing in both user and kernel space to end up with invariant pointers relative to the base address (which will be different in kernel and user space). If you are building a special purpose embedded system, rather than a just a driver for use in a general purpose system, then there are other ways to make the code faster that involve giving up some of the guarantees that you normally get from a protected mode OS. My personal suggestion, given what I know of your intended application, would be to use the first approach. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 13 10:48:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id EB34337B43A for ; Wed, 13 Feb 2002 10:48:10 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g1DIlwg01147; Wed, 13 Feb 2002 10:47:59 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200202131847.g1DIlwg01147@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "mike varga" Cc: "Steve Kargl" , freebsd-arch@freebsd.org Subject: Re: bus_dma_load_uio() function In-reply-to: Your message of "Tue, 12 Feb 2002 17:33:37 PST." <000701c1b42e$7835eda0$b210a8c0@netscreen5> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Feb 2002 10:47:58 -0800 From: Michael 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 > Yes I did, but thank you > for replying. > > My question essentially > boils down to,"How do you > map and lock user pages (buffers) > for use in a driver that wants > to do a DMA directly > from/to them. > > It removes unnecessary > copies. Typically, you let the kernel do this for you, via the physio interface. -- To announce that there must be no criticism of the president or that we are to stand by the president right or wrong is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosvelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 13 17:15:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 98B2337B405; Wed, 13 Feb 2002 17:15:22 -0800 (PST) Received: from pool0388.cvx40-bradley.dialup.earthlink.net ([216.244.43.133] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16bAUb-0005B5-00; Wed, 13 Feb 2002 17:15:21 -0800 Message-ID: <3C6B0F9F.BC4C102E@mindspring.com> Date: Wed, 13 Feb 2002 17:15:11 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith Cc: mike varga , Steve Kargl , freebsd-arch@freebsd.org Subject: Re: bus_dma_load_uio() function References: <200202131847.g1DIlwg01147@mass.dis.org> 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 Michael Smith wrote: > > It removes unnecessary > > copies. > > Typically, you let the kernel do this for you, via the physio interface. Mike's particular use would see any paging as a very big stall. Locking down mappings vs. wiring down pages pretty much wants the pages to be in the KVA space and mapped into the process, instead of vice-versa. His repsonse requirements are very similar to those of a video capture card. PS: Mike: make sure it generates interrupts; see Luigi Rizzo's current work with polling: even with polling, the trigger is an interrupt. ;^). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 14 12:30:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 3DFC437B42F for ; Thu, 14 Feb 2002 12:30:29 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA12886 for ; Thu, 14 Feb 2002 15:30:28 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g1EKTw500769; Thu, 14 Feb 2002 15:29:58 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15468.7750.125431.87954@grasshopper.cs.duke.edu> Date: Thu, 14 Feb 2002 15:29:58 -0500 (EST) To: freebsd-arch@freebsd.org Subject: 3rd party binary modules X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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'm working for a company that distributes drivers for its network interconnect boards. We currently distribute all our drivers in source form. As a convenience to our customers, we also distribute binary drivers for many platforms. I'd like to package a binary module for FreeBSD. While I realize that the ABI is stable thoughout the RELENG_4 branch, I'm not familiar with the correct way to build a driver for generic binary distribution. If I build the driver as part of a normal GENERIC kernel build procedure, should I expect it to work in, say, SMP environments? This is a network driver which does ethernet emulation, as well as os-bypass networking using an mmaped cdev & a few ioctls. Its not doing any locking (aside from spls) and its not installing any system calls. Thanks, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 14 21:11:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from yahoo.com (host-64-110-31-18.interpacket.net [64.110.31.18]) by hub.freebsd.org (Postfix) with SMTP id 0BB6737B431 for ; Thu, 14 Feb 2002 21:09:37 -0800 (PST) From: "MR MICHEAL ADAM" To: Subject: Partnership Proposal Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 14 Feb 2002 06:17:41 -0000 Reply-To: "MR MICHEAL ADAM" Content-Transfer-Encoding: 8bit Message-Id: <20020215050937.0BB6737B431@hub.freebsd.org> 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 ATTN: THE PRESIDENT/CEO Dear Sir / Madam, I am Dr. Mrs. Marian Abacha, wife to the late Nigerian Head of state, General Sani Abacha who died on the 8th of June 1998 while still on active service for our Country. I am contacting you with the hope that you will be of great assistance to me, I currently have within my reach the sum of 76MILLION U.S dollars cash which l intend to use for investment purposes outside Nigeria. This money came as a result of a payback contract deal between my husband and a Russian firm in our country's multi-billion dollar Ajaokuta steel plant. The Russian partners returned my husband's share being the above sum after his death. Presently, the new civilian Government has intensified their probe into my husband's financial resources, which has led to the freezing of all our accounts, local and foreign, the revoking of all our business licenses and the arrest of my First son. In view of this I acted very fast to withdraw this money from one of our finance houses before it was closed down. I have deposited the money in a security vault for safe keeping with the help of very loyal officials of my late husband. No record is known about this fund by the government because there is no documentation showing that we received such funds. Due to the current situation in the country and government attitude to my financial affairs, I cannot make use of this money within. Bearing in mind that you may assist me, 20% of the total amount will be paid to you for your assistance, while 5% will be set aside for expenses incurred by the parties involved and this will be paid before sharing. Half of my75% will be paid in to my account on your instruction once the money hits your account, while the other half will be invested by your humble self in any viable business venture you deem fit, with you as manager of the invested funds. Remunerations, during the investment period will be on a 50/50 basis. Your URGENT response is needed. All correspondence must be through my lawyer,fax:234-1-4709814. Attentioned to my attorney (HAMZA IBU). Please do not forget to include your direct tel/fax line for easy reach. I hope I can trust you with my family's last financial hope.Regards Dr. Mrs. Marian Sani Abacha. C/o HAMZA IBU (counsel) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 15 12:27:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from antipater.hosting.pacbell.net (antipater.hosting.pacbell.net [216.100.99.13]) by hub.freebsd.org (Postfix) with ESMTP id 4C43237B416 for ; Fri, 15 Feb 2002 12:27:33 -0800 (PST) Received: from misha1 (adsl-64-172-38-74.dsl.snfc21.pacbell.net [64.172.38.74]) by antipater.hosting.pacbell.net id PAA10251; Fri, 15 Feb 2002 15:27:32 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <003701c1b65c$53138840$b210a8c0@netscreen5> Reply-To: "mike varga" From: "mike varga" To: Subject: reverse vtophys() Date: Fri, 15 Feb 2002 12:06:57 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C1B619.43E05EE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C1B619.43E05EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is there a function that exists=20 that converts a physical address to=20 a process's virtual address? ------=_NextPart_000_0034_01C1B619.43E05EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is there a function that = exists 
that converts a physical address = to=20
a process's virtual=20 address?
 
 
 
------=_NextPart_000_0034_01C1B619.43E05EE0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 15 18:52:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from antipater.hosting.pacbell.net (antipater.hosting.pacbell.net [216.100.99.13]) by hub.freebsd.org (Postfix) with ESMTP id 478B937B486 for ; Fri, 15 Feb 2002 18:52:35 -0800 (PST) Received: from misha1 (adsl-64-172-38-74.dsl.snfc21.pacbell.net [64.172.38.74]) by antipater.hosting.pacbell.net id VAA04131; Fri, 15 Feb 2002 21:52:34 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <009b01c1b692$1beea670$b210a8c0@netscreen5> Reply-To: "mike varga" From: "mike varga" To: Subject: virtual address from physical Date: Fri, 15 Feb 2002 18:31:58 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01C1B64F.0D41EB20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 This is a multi-part message in MIME format. ------=_NextPart_000_0098_01C1B64F.0D41EB20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone know of an easy way to get a process's virtual address from a physical address? Linux has functions that allow programmers to go both ways. --virtual to physical=20 --physical to virtual Are there analogs in=20 FreeBSD? I am aware of vtophys(), but can not find anything=20 that goes the other way. I could search a process's page table for a base/len combination that my physical address falls within=20 and then add the offset? ------=_NextPart_000_0098_01C1B64F.0D41EB20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does anyone know of an = easy
way to get a process's = virtual
address from a physical = address?
 
Linux has functions that = allow
programmers to go both = ways.
--virtual to physical
--physical to virtual
 
Are there analogs in
FreeBSD?
 
I am aware of vtophys(),
but can not find anything
that goes the other way.
 
I could search a process's
page table for a base/len = combination
that my physical address falls within =
and then add the = offset?
------=_NextPart_000_0098_01C1B64F.0D41EB20-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 15 19:21:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sunny.newgold.net (durham-ar1-174-172.durham.dsl.gtei.net [4.40.174.172]) by hub.freebsd.org (Postfix) with ESMTP id BD48D37B404 for ; Fri, 15 Feb 2002 19:21:48 -0800 (PST) Received: from sunny.newgold.net (jmallett@localhost [IPv6:::1]) by sunny.newgold.net (8.12.1/8.12.1) with ESMTP id g1G30YDF026805 for ; Sat, 16 Feb 2002 03:00:35 GMT Received: (from jmallett@localhost) by sunny.newgold.net (8.12.1/8.12.1/Submit) id g1G30XEV016470 for freebsd-arch@freebsd.org; Sat, 16 Feb 2002 03:00:33 GMT Date: Sat, 16 Feb 2002 03:00:33 +0000 From: "J. Mallett" To: freebsd-arch@freebsd.org Subject: Generalisation of Base64 function prototypes. Message-ID: <20020216030032.A12929@NewGold.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.21i Organisation: New Gold Technology 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, I've been working on base64 ala MIME support for uudecode(1) and uuencode(1), as part of standards conformance projects. Rather than re-implement base64 stuff inline, I looked high and low for base64 functions in libc. Eventually Mike Barcroft came to my aid with b64_pton and b64_ntop, undocumented interfaces implemented in lib/libc/net/ and prototyped and wrapped in . Rather than include networking types and functionality in uuencode and uudecode (silly) I put the prototypes and namespace wrappers in the code inline, and my current patch represents this, and I would probably end up getting it into the tree like this, I suppose, as there is no equally or less evil method of doing the right thing here. Except of course, what I proposed above the prototypes and preprocessor definitions I so hastily inserted, and that is moving b64_* stuff from to . The interfaces are very generalised and as is obvious by the fact I have working base64 uu*code, they can be applied to things other than networking, and certainly more than just stuff that makes use of resolver code. Existing users of b64_* may need changed to include as well as , however I would _guess_ that very few consumers of said prototypes do not already get included. I won't go into the issue of whether the namespace is too similar to networking functions and should be changed, nor whether the implementations should be repocopied to a non-networking location in libc, as while I have opinions of such things, I can't speak for how useful or purposeful such may be. I can only say that very soon, hopefully, uuencode(1) and uudecode(1) will have base64 functionality, as almost everyone else (aside the other BSDs) tends to be using this in addition to UUENCODE format, and that I think we should not duplicate the code, and that unless prototypes and namespace wrappers are placed into , or somewhere else independant of needing tons of networking headers, the code will have to have extremely out of place prototypes in itself. Just an idea, anyway. Insight is greatly appriciated, as well as discussion of such a change to decide whether it would be practical. Thanks for your time and attention. -- J. Mallett Need a modular BSD solution? http://www.xMach.org/ jmallett@{xMach.org,tasam.com,e-u-a.net} deepthroat@bsdconspiracy.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 15 20:12:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 0F18437B402 for ; Fri, 15 Feb 2002 20:12:27 -0800 (PST) Received: from pool0137.cvx21-bradley.dialup.earthlink.net ([209.179.192.137] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16bwD3-00010A-00; Fri, 15 Feb 2002 20:12:25 -0800 Message-ID: <3C6DDC01.2C7AE9C0@mindspring.com> Date: Fri, 15 Feb 2002 20:11:45 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mike varga Cc: freebsd-arch@freebsd.org Subject: Re: virtual address from physical References: <009b01c1b692$1beea670$b210a8c0@netscreen5> 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 mike varga wrote: Quit sending HTML email to -arch. [ ... applying magic decoder ring ... ] | Does anyone know of an easy | way to get a process's virtual | address from a physical address? | | Linux has functions that allow | programmers to go both ways. | --virtual to physical | --physical to virtual | | Are there analogs in | FreeBSD? | | I am aware of vtophys(), | but can not find anything | that goes the other way. | | I could search a process's | page table for a base/len combination | that my physical address falls within | and then add the offset? This is what you have to do; it's a pmap lookup. There are a couple of utility functions that know how to do this, and you can crib code from them. They are in the i386/pmap.c code. In general, you can never know what physical memory is backing a user page at a given time. That is, if you make a call to a driver to schedule an I/O to complete at a later time, unless the pages you are planning on using for the I/O are wired down for the duration of the I/O (guaranteed to never be swapped out and overwritten), by the time the device decides to DMA into/out of that memory area, the physical pages where it will be writing to/reading from may not contain that process memory that they contained before, and you may be DMA'ing data to the device from some random page, or to some random page, that's actually in another process or in the kernel, by the time the driver does its thing. This is why it's better to allocated a wired down region of the KVA space, and use that, instead, with the user space address mapping being well known to the process, and the region shared between a physical address and not. Passing the physical address back from the driver is not a good idea. The pmap lookup is expensive (as you've noticed, in your proposed workaround). No matter how you look at it, it will be a reverse lookup. The best you are going to get is a contibuous wired region that you know the start address, because you told the driver, or the driver allocated it in the KVA space, so that when the address is passed back from the driver, you can do a simple subtract (using your knowledge that the mapping is contiguous in physical memory) to map between KVA and physical address. The mapping to the user space address relies on the mapping of the kernel address to a user space address. For this reason, you should map the device allocated KVA space into the process (via mmap()), or map the SYSVSHM space into the kernel address space by ketting the KVA address from the user space address via an ioctl() to the device. Because using the second method would not guarantee that the pages would be physically contiguous, requiring a (much faster than the reverse) forward lookup for the pmap entry, mmap'ing memory allocated by the device driver is preferred. On Linux, this doesn't matter much, since without a unified VM and buffer cache, the additional copy overhead that results from maintaining VM and buffer cache coherency for the data dwarfs the overhead of doing the reverse lookup. This means that on Linux, you save a copy by doing DMA directly into user memory, whereas on FreeBSD, the copy is already saved for you, so doing extra work to DMA into a specific user buffer is meaningless, so long as that buffer is shared between the KVA and user address spaces (e.g. mmap or SYSVSHM, etc.). If what you wanted to do were a normal thing, you would want: 1) A hash so that the reverse lookup was O(1) for bucket identification, with a minor requirement for forward lookup on top of that in case of collision 2) Some "magic" interface to force wiring down of user pages, so that they don't move out from under the DMA between the time the request to the hardware is issued, and the time that the hardware completes the request and tries to read/write the memory, which may no longer be there. If what you are talking about is a small number of memory, then you could perform the forward translation once, at request time. You will still need to wire the memory down, and there is really no user space interface for that; you will have to wire down the memory in the driver itself, and keep an incomplete request descriptor list in your driver, and do the lookups there (rather than pmap), to do the reverse translation, and to let the driver control wiring down and knowing when to unwire the pages (after the request(s) using them have all completed). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 15 21: 0:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7299E37B402; Fri, 15 Feb 2002 21:00:49 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1G50j145638; Fri, 15 Feb 2002 21:00:45 -0800 (PST) (envelope-from dillon) Date: Fri, 15 Feb 2002 21:00:45 -0800 (PST) From: Matthew Dillon Message-Id: <200202160500.g1G50j145638@apollo.backplane.com> To: arch@freebsd.org Cc: phk@critter.freebsd.dk, jhb@freebsd.org, peter@wemm.org, jake@locore.ca Subject: gettimeofday() and copyout(). Is copyout() MPSAFE on non-i386 archs? 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 Poul indicated today that the microtime() call that gettimeofday() uses is MPSAFE. copyout() on I386 is MPSAFE, and from my perusal of the other archs it appears to be MPSAFE for alpha, ia64, and sparc64 as well. This would seem to indicate that Giant can be removed from the gettimeofday() system call. I would like those familiar with the other archs to verify that copyout() is MPSAFE on them. I am testing Giant removal for this syscall on i386 now. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 15 23:38: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (dhcp28.gw.tislabs.com [192.94.214.128]) by hub.freebsd.org (Postfix) with ESMTP id 4FD9B37B402; Fri, 15 Feb 2002 23:38:01 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id g1G7XHW06990; Sat, 16 Feb 2002 08:33:31 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: arch@freebsd.org, jhb@freebsd.org, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and copyout(). Is copyout() MPSAFE on non-i386 archs? In-Reply-To: Your message of "Fri, 15 Feb 2002 21:00:45 PST." <200202160500.g1G50j145638@apollo.backplane.com> Date: Sat, 16 Feb 2002 08:33:17 +0100 Message-ID: <6988.1013844797@critter.freebsd.dk> 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 <200202160500.g1G50j145638@apollo.backplane.com>, Matthew Dillon wri tes: > Poul indicated today that the microtime() call that gettimeofday() uses > is MPSAFE. copyout() on I386 is MPSAFE, and from my perusal of the > other archs it appears to be MPSAFE for alpha, ia64, and sparc64 > as well. > > This would seem to indicate that Giant can be removed from the > gettimeofday() system call. I would like those familiar with the > other archs to verify that copyout() is MPSAFE on them. I am testing > Giant removal for this syscall on i386 now. Make sure to run something which abuses gettimeofday() for select, maybe netscape or some other multi-threaded nightmare. -- 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 Sat Feb 16 10:42:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2AEE537B404 for ; Sat, 16 Feb 2002 10:42:17 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1GIgFF89658; Sat, 16 Feb 2002 10:42:15 -0800 (PST) (envelope-from dillon) Date: Sat, 16 Feb 2002 10:42:15 -0800 (PST) From: Matthew Dillon Message-Id: <200202161842.g1GIgFF89658@apollo.backplane.com> To: Peter Wemm Cc: Dan Eischen , arch@FreeBSD.ORG Subject: MFC makecontext(), getcontext(), setcontext()?, also would be nice to have some cleanups References: <20020206195918.6350039F1@overcee.wemm.org> 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 It would be nice if getcontext() and setcontext() could be told not to screw around with the signal mask, similar to what sigsetjmp() and siglongjmp() do if the savemask is empty. Perhaps something like this: BEFORE: 2: PIC_PROLOGUE pushl $0 /* oset = NULL */ pushl %eax /* set = &ucp->uc_sigmask */ pushl $3 /* how = SIG_SETMASK */ call PIC_PLT(CNAME(_sigprocmask)) addl $12, %esp PIC_EPILOGUE AFTER: 2: PIC_PROLOGUE testl (%eax) <<<<<<<<<<< ADD jz 21f <<<<<<<<<<< ADD pushl $0 /* oset = NULL */ pushl %eax /* set = &ucp->uc_sigmask */ pushl $3 /* how = SIG_SETMASK */ call PIC_PLT(CNAME(_sigprocmask)) addl $12, %esp PIC_EPILOGUE testl %eax,%eax jnz 5f 21: <<<<<<<<<<< ADD (make same change in both setcontext() and getcontext()) This way these calls could be used to replace the alternate signal stack, sigsetjmp()/setlongjmp() junk that has to be done now in roll-your-own threads systems. Any objections to me doing this? I would also like to MFC these functions to -stable at some point. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 11: 6:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E286837B400 for ; Sat, 16 Feb 2002 11:06:43 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1GJ6hJ12493; Sat, 16 Feb 2002 11:06:43 -0800 (PST) (envelope-from dillon) Date: Sat, 16 Feb 2002 11:06:43 -0800 (PST) From: Matthew Dillon Message-Id: <200202161906.g1GJ6hJ12493@apollo.backplane.com> To: Matthew Dillon Cc: Peter Wemm , Dan Eischen , arch@FreeBSD.ORG Subject: Re: MFC makecontext(), getcontext(), setcontext()?, also would be nice to have some cleanups References: <20020206195918.6350039F1@overcee.wemm.org> <200202161842.g1GIgFF89658@apollo.backplane.com> 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, actually I'm wrong here. I didn't realize that these were statically setting the signal mask. Let me rephrase this: There are many cases where the signal mask does not have to be messed with. It would be really nice if setcontext()/getcontext() could be told not to screw with it, perhaps with a flag. Making a system call every single time setcontext() or getcontext() is called is extremely wasteful and slows down the context switch by an insane amount. So scrap my previous sample code and instead replace with code that simply checks the flags field for a flag that tells it to ignore the signal mask. -Matt Matthew Dillon : : It would be nice if getcontext() and setcontext() could be told : not to screw around with the signal mask, similar to what sigsetjmp() : and siglongjmp() do if the savemask is empty. Perhaps something like : this: : : BEFORE: :... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 12:20:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 04A5F37B400 for ; Sat, 16 Feb 2002 12:20:14 -0800 (PST) Received: from vigrid.com (pm3-pt39.pcnet.net [206.105.29.113]) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g1GKK7oS018962; Sat, 16 Feb 2002 15:20:08 -0500 (EST) Message-ID: <3C6EC0A2.419FDA74@vigrid.com> Date: Sat, 16 Feb 2002 15:27:14 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: MFC makecontext(), getcontext(), setcontext()?, also would be nice to have some cleanups References: <20020206195918.6350039F1@overcee.wemm.org> <200202161842.g1GIgFF89658@apollo.backplane.com> 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 Matthew Dillon wrote: > > It would be nice if getcontext() and setcontext() could be told > not to screw around with the signal mask, similar to what sigsetjmp() > and siglongjmp() do if the savemask is empty. Perhaps something like > this: > [...] > (make same change in both setcontext() and getcontext()) > > This way these calls could be used to replace the alternate signal > stack, sigsetjmp()/setlongjmp() junk that has to be done now in > roll-your-own threads systems. Yeah, I originally thought about also making _getcontext and _setcontext, similar to _setjmp/_longjmp which don't change the signal mask. The current implementation of these functions in libc will be replaced with a system call as soon as I incorporate bde's comments wrt FPU state handling. They simply become: .weak CNAME(getcontext) .set CNAME(getcontext),CNAME(__getcontext) ENTRY(__getcontext) popl %ecx /* save return address */ movl 0(%esp), %eax /* get ucp */ pushl $0 /* NULL */ pushl %eax /* ucp */ pushl $0 /* leave slot for return address */ movl $SYS_getsetcontext, %eax KERNCALL addl $8, %esp movl %ecx, 0(%esp) /* return to address saved in %ecx */ jb 1f xorl %eax, %eax /* always returns 0 upon success */ ret 1: PIC_PROLOGUE jmp PIC_PLT(HIDENAME(cerror)) and similar for setcontext and swapcontext. We do need the something similar to the current implementation for the threads library though. For KSE threads, we may actually need to know when XXX_setcontext() is done so we can clear an "in scheduler" or "context in use" flag. I was just going to add these functions to the threads library, but perhaps we can find something that isn't just useful for the threads library. I was thinking along the lines of: _thr_setcontext(const ucontext_t *ucp, long *done) We can do away with "done" in the threads library, but it would probably mean copying an interrupted context before resuming it (so the context doesn't get clobbered if the thread gets interrupted in the middle of resuming it). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 12:33:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 36E1637B417; Sat, 16 Feb 2002 12:33:28 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1GKXOf13029; Sat, 16 Feb 2002 12:33:24 -0800 (PST) (envelope-from dillon) Date: Sat, 16 Feb 2002 12:33:24 -0800 (PST) From: Matthew Dillon Message-Id: <200202162033.g1GKXOf13029@apollo.backplane.com> To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: gettimeofday() and crhold()/crfree() (was Re: gettimeofday() and copyout(). Is copyout() MPSAFE on non-i386 archs? ) References: <6988.1013844797@critter.freebsd.dk> 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 :Make sure to run something which abuses gettimeofday() for select, :maybe netscape or some other multi-threaded nightmare. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :phk@FreeBSD.ORG | TCP/IP since RFC 956 I can run some backplane database stuff, that's fairly select/gettimeofday intensive. This is what I am running right now (see below). When combined with the /bin/ps change I just comitted and gdb'ing -k kernel.debug /dev/mem to look at where the process is getting stuck when running two of them on an SMP system. It looks like it is mainly getting stuck in the mtx_lock(&Giant) call around the crfree() call in trap.c (the syscall code). Does anyone mind if I fix the credential code? Locking Giant for every syscall doesn't make any sense, nor does calling FREE() inside crfree() or embedding an internal mutex in the ucred. It can all be done with mtxpool-protected credentials and a ucred freelist. It would take me less then an hour to fix it but I don't want to step on any toes if someone else is already on it. -Matt Matthew Dillon /* * TESTGTOD.C */ #include #include #include #include int main(int ac, char **av) { struct timeval tv1; struct timeval tv2; int count= 0; int count_sec = 0; pid_t pid = getpid(); gettimeofday(&tv1, NULL); for (;;) { int us; gettimeofday(&tv2, NULL); ++count_sec; us = (tv2.tv_usec + 1000000 - tv1.tv_usec) + (tv2.tv_sec - tv1.tv_sec - 1) * 1000000; if (us > 1000000) break; } gettimeofday(&tv1, NULL); for (;;) { gettimeofday(&tv2, NULL); ++count; if (count == count_sec) { int us = (tv2.tv_usec + 1000000 - tv1.tv_usec) + (tv2.tv_sec - tv1.tv_sec - 1) * 1000000; printf("pid %d gtod/sec %d\n", (int)pid, (int)((int64_t)count * 1000000 / us)); count = 0; tv1 = tv2; } } return(0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 13:15:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 91A6037B404; Sat, 16 Feb 2002 13:15:30 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1GLFSe32349; Sat, 16 Feb 2002 13:15:28 -0800 (PST) (envelope-from dillon) Date: Sat, 16 Feb 2002 13:15:28 -0800 (PST) From: Matthew Dillon Message-Id: <200202162115.g1GLFSe32349@apollo.backplane.com> To: Poul-Henning Kamp , arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: timing results for gettimeofday() (without any credential fixes) 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 CURRENT 2xCPU SMP BUILD Original gettimeofday() code one TG running: 350000/sec two TGs running: 55000/sec per TG (no, that isn't a type-o) CURRENT 2xCPU SMP BUILD W/Giant removed from gettimeofday() one TG running: 375000/sec two TGs running: 301000/sec per TG (due to ucred Giant issues) (tests run on 2xCPU 1.2 GHz DELL2550's) With crhold()/crfree() also fixed I would expect both TG's to operate at at least 350K calls/sec. This just goes to show how badly cache mastership changes can mess up high-performance procedure calls. Holding Giant in the original code dropped performance by a factor of 10, far more then the factor of 2 it ought to have dropped it by. L1 Cache mastership changes are almost certainly to blame. In contrast, the same machine running stable: STABLE 2xCPU SMP BUILD (note gettimeofday() on stable is marked MPSAFE): one TG running: 192402/sec two TGs running: 95900/sec I'm not sure what is going on in stable, because gettimeofday() is in fact marked MPSAFE. I think it may be the scheduler doing something weird. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 13:19:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5F51D37B41A; Sat, 16 Feb 2002 13:19:22 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1GLJKX32402; Sat, 16 Feb 2002 13:19:20 -0800 (PST) (envelope-from dillon) Date: Sat, 16 Feb 2002 13:19:20 -0800 (PST) From: Matthew Dillon Message-Id: <200202162119.g1GLJKX32402@apollo.backplane.com> To: Poul-Henning Kamp , arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: timing results for gettimeofday() (without any credential fixes) References: <200202162115.g1GLFSe32349@apollo.backplane.com> 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 :code dropped performance by a factor of 10, far more then the factor of 2 Er, I meant a factor of 6. Still much worse then the expected factor of 2 or 3. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 13:47:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 1B33637B400; Sat, 16 Feb 2002 13:47:10 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id E594AAE46D; Sat, 16 Feb 2002 13:47:09 -0800 (PST) Date: Sat, 16 Feb 2002 13:47:09 -0800 From: Alfred Perlstein To: Matthew Dillon Cc: Poul-Henning Kamp , arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday() and copyout(). Is copyout() MPSAFE on non-i386 archs? ) Message-ID: <20020216214709.GA12136@elvis.mu.org> References: <6988.1013844797@critter.freebsd.dk> <200202162033.g1GKXOf13029@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202162033.g1GKXOf13029@apollo.backplane.com> User-Agent: Mutt/1.3.27i 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 * Matthew Dillon [020216 12:33] wrote: > :Make sure to run something which abuses gettimeofday() for select, > :maybe netscape or some other multi-threaded nightmare. > : > :-- > :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > :phk@FreeBSD.ORG | TCP/IP since RFC 956 > > I can run some backplane database stuff, that's fairly select/gettimeofday > intensive. > > This is what I am running right now (see below). When combined with the > /bin/ps change I just comitted and gdb'ing -k kernel.debug /dev/mem to > look at where the process is getting stuck when running two of them on an > SMP system. It looks like it is mainly getting stuck in the > mtx_lock(&Giant) call around the crfree() call in trap.c (the syscall > code). > > Does anyone mind if I fix the credential code? Locking Giant for > every syscall doesn't make any sense, nor does calling FREE() inside > crfree() or embedding an internal mutex in the ucred. It can all > be done with mtxpool-protected credentials and a ucred freelist. It > would take me less then an hour to fix it but I don't want to step on > any toes if someone else is already on it. Go ahead with using mutex pools for creds, I thought I'd done it already but it looks like I only got to struct file and struct uidinfo. :) I do sort of think that keeping your own cred freelist is probably a bad idea especially with what Jeff R has coming down the pipe for us. But we can take that out later if something better comes along. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 14: 0:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 36B0037B402; Sat, 16 Feb 2002 14:00:06 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1GM04F39752; Sat, 16 Feb 2002 14:00:04 -0800 (PST) (envelope-from dillon) Date: Sat, 16 Feb 2002 14:00:04 -0800 (PST) From: Matthew Dillon Message-Id: <200202162200.g1GM04F39752@apollo.backplane.com> To: Alfred Perlstein Cc: Poul-Henning Kamp , arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday() and copyout(). Is copyout() MPSAFE on non-i386 archs? ) References: <6988.1013844797@critter.freebsd.dk> <200202162033.g1GKXOf13029@apollo.backplane.com> <20020216214709.GA12136@elvis.mu.org> 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 :Go ahead with using mutex pools for creds, I thought I'd done it :already but it looks like I only got to struct file and struct :uidinfo. :) : :I do sort of think that keeping your own cred freelist is probably :a bad idea especially with what Jeff R has coming down the pipe for :us. But we can take that out later if something better comes along. : :-Alfred Well, I dunno... I'm warming to the idea if it in fact eases the job of pushing Giant down. It seems so easy to do for the ucred, though of course I am not trying to proactively trim down the size of the freelist (yet)... but even that would be fairly simple to do in the allocation code by adding a count of the number of items in the freelist. It would be another ten lines of code relative to the patch I just posted. int cr_free_count; .. in allocation code do while (cr_free_count > HYSTERESIS) { ... free ... } -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 14: 3:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C316437B405; Sat, 16 Feb 2002 14:03:33 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1GM3Vu39770; Sat, 16 Feb 2002 14:03:31 -0800 (PST) (envelope-from dillon) Date: Sat, 16 Feb 2002 14:03:31 -0800 (PST) From: Matthew Dillon Message-Id: <200202162203.g1GM3Vu39770@apollo.backplane.com> To: Alfred Perlstein Cc: Poul-Henning Kamp , arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday() and copyout(). Is copyout() MPSAFE on non-i386 archs? ) References: <6988.1013844797@critter.freebsd.dk> <200202162033.g1GKXOf13029@apollo.backplane.com> <20020216214709.GA12136@elvis.mu.org> 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 This is interesting: SHELL1> ./tg & SHELL1> ./tg & ... 255000 gettimeofday calls per second each SHELL1> ./tg SHELL2> ./tg ... 322000 gettimeofday calls per second each I think this is due to the same ucred being shared from the two ./tg runs from the same shell, indication further mutex contention above and beyond whatever contention was occuring before with separate instances of the ucred (due to sshd setuid'ing and such when starting a new shell). I'm not proposing any changes, this is just another data point that we may want to keep in mind. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 17: 0:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 8110337B421; Sat, 16 Feb 2002 17:00:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020217010013.KMAT2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Sun, 17 Feb 2002 01:00:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA43282; Sat, 16 Feb 2002 16:49:47 -0800 (PST) Date: Sat, 16 Feb 2002 16:49:45 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: Alfred Perlstein , Poul-Henning Kamp , arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday() and copyout(). Is copyout() MPSAFE on non-i386 archs? ) In-Reply-To: <200202162200.g1GM04F39752@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1508433265-1013906985=:39539" 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1508433265-1013906985=:39539 Content-Type: TEXT/PLAIN; charset=US-ASCII the whole point is moot.. you don't need to get or drop the creds at all.. see the attached patch I'm about to commit a version of.. On Sat, 16 Feb 2002, Matthew Dillon wrote: > > :Go ahead with using mutex pools for creds, I thought I'd done it > :already but it looks like I only got to struct file and struct > :uidinfo. :) > : > :I do sort of think that keeping your own cred freelist is probably > :a bad idea especially with what Jeff R has coming down the pipe for > :us. But we can take that out later if something better comes along. > : > :-Alfred > > Well, I dunno... I'm warming to the idea if it in fact eases the job > of pushing Giant down. It seems so easy to do for the ucred, though > of course I am not trying to proactively trim down the size of the > freelist (yet)... but even that would be fairly simple to do in the > allocation code by adding a count of the number of items in the freelist. > > It would be another ten lines of code relative to the patch > I just posted. int cr_free_count; .. in allocation code do > while (cr_free_count > HYSTERESIS) { ... free ... } > > -Matt > Matthew Dillon > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > --0-1508433265-1013906985=:39539 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=thediff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=thediff PyBpMzg2L2NvbmYvTElOVA0KPyBtb2R1bGVzL25ldGdyYXBoL2tzb2NrZXQv bmdfa3NvY2tldC5rbGQNCj8gbW9kdWxlcy9uZXRncmFwaC9rc29ja2V0L25n X2tzb2NrZXQua28NCkluZGV4OiBpMzg2L2kzODYvdHJhcC5jDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lz L2kzODYvaTM4Ni90cmFwLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjIx MQ0KZGlmZiAtdSAtcjEuMjExIHRyYXAuYw0KLS0tIGkzODYvaTM4Ni90cmFw LmMJMTAgSmFuIDIwMDIgMTE6NDk6NTQgLTAwMDAJMS4yMTENCisrKyBpMzg2 L2kzODYvdHJhcC5jCTEzIEZlYiAyMDAyIDAxOjA3OjA3IC0wMDAwDQpAQCAt MjU2LDkgKzI1Niw4IEBADQogCQlzdGlja3MgPSB0ZC0+dGRfa3NlLT5rZV9z dGlja3M7DQogCQl0ZC0+dGRfZnJhbWUgPSAmZnJhbWU7DQogCQlLQVNTRVJU KHRkLT50ZF91Y3JlZCA9PSBOVUxMLCAoImFscmVhZHkgaGF2ZSBhIHVjcmVk IikpOw0KLQkJUFJPQ19MT0NLKHApOw0KLQkJdGQtPnRkX3VjcmVkID0gY3Jo b2xkKHAtPnBfdWNyZWQpOw0KLQkJUFJPQ19VTkxPQ0socCk7DQorCQlpZiAo dGQtPnRkX3VjcmVkICE9IHAtPnBfdWNyZWQpIA0KKwkJCWFxdWlyZV91Y3Jl ZCh0ZCwgcCk7DQogDQogCQlzd2l0Y2ggKHR5cGUpIHsNCiAJCWNhc2UgVF9Q UklWSU5GTFQ6CS8qIHByaXZpbGVnZWQgaW5zdHJ1Y3Rpb24gZmF1bHQgKi8N CkBAIC02NDQsMTAgKzY0MywxMiBAQA0KIAl1c2VycmV0KHRkLCAmZnJhbWUs IHN0aWNrcyk7DQogCW10eF9hc3NlcnQoJkdpYW50LCBNQV9OT1RPV05FRCk7 DQogdXNlcm91dDoNCisjaWZkZWYJSU5WQVJJQU5UUw0KIAltdHhfbG9jaygm R2lhbnQpOw0KIAljcmZyZWUodGQtPnRkX3VjcmVkKTsNCiAJbXR4X3VubG9j aygmR2lhbnQpOw0KIAl0ZC0+dGRfdWNyZWQgPSBOVUxMOw0KKyNlbmRpZg0K IG91dDoNCiAJcmV0dXJuOw0KIH0NCkBAIC05NTQsOSArOTU1LDggQEANCiAJ c3RpY2tzID0gdGQtPnRkX2tzZS0+a2Vfc3RpY2tzOw0KIAl0ZC0+dGRfZnJh bWUgPSAmZnJhbWU7DQogCUtBU1NFUlQodGQtPnRkX3VjcmVkID09IE5VTEws ICgiYWxyZWFkeSBoYXZlIGEgdWNyZWQiKSk7DQotCVBST0NfTE9DSyhwKTsN Ci0JdGQtPnRkX3VjcmVkID0gY3Job2xkKHAtPnBfdWNyZWQpOw0KLQlQUk9D X1VOTE9DSyhwKTsNCisJaWYgKHRkLT50ZF91Y3JlZCAhPSBwLT5wX3VjcmVk KSANCisJCWFxdWlyZV91Y3JlZCh0ZCwgcCk7DQogCXBhcmFtcyA9IChjYWRk cl90KWZyYW1lLnRmX2VzcCArIHNpemVvZihpbnQpOw0KIAljb2RlID0gZnJh bWUudGZfZWF4Ow0KIAlvcmlnX3RmX2VmbGFncyA9IGZyYW1lLnRmX2VmbGFn czsNCkBAIC0xMDk5LDEwICsxMDk5LDEyIEBADQogCSAqLw0KIAlTVE9QRVZF TlQocCwgU19TQ1gsIGNvZGUpOw0KIA0KKyNpZmRlZglJTlZBUklBTlRTDQog CW10eF9sb2NrKCZHaWFudCk7DQogCWNyZnJlZSh0ZC0+dGRfdWNyZWQpOw0K IAltdHhfdW5sb2NrKCZHaWFudCk7DQogCXRkLT50ZF91Y3JlZCA9IE5VTEw7 DQorI2VuZGlmDQogI2lmZGVmIFdJVE5FU1MNCiAJaWYgKHdpdG5lc3NfbGlz dCh0ZCkpIHsNCiAJCXBhbmljKCJzeXN0ZW0gY2FsbCAlcyByZXR1cm5pbmcg d2l0aCBtdXRleChzKSBoZWxkXG4iLA0KSW5kZXg6IGtlcm4va2Vybl9mb3Jr LmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9u Y3ZzL3NyYy9zeXMva2Vybi9rZXJuX2ZvcmsuYyx2DQpyZXRyaWV2aW5nIHJl dmlzaW9uIDEuMTMwDQpkaWZmIC11IC1yMS4xMzAga2Vybl9mb3JrLmMNCi0t LSBrZXJuL2tlcm5fZm9yay5jCTcgRmViIDIwMDIgMjM6MDY6MjYgLTAwMDAJ MS4xMzANCisrKyBrZXJuL2tlcm5fZm9yay5jCTEzIEZlYiAyMDAyIDAxOjA3 OjExIC0wMDAwDQpAQCAtNzk5LDEwICs3OTksMTIgQEANCiAJCWt0aHJlYWRf ZXhpdCgwKTsNCiAJfQ0KIAlQUk9DX1VOTE9DSyhwKTsNCisjaWZkZWYJSU5W QVJJQU5UUw0KIAltdHhfbG9jaygmR2lhbnQpOw0KIAljcmZyZWUodGQtPnRk X3VjcmVkKTsNCiAJbXR4X3VubG9jaygmR2lhbnQpOw0KIAl0ZC0+dGRfdWNy ZWQgPSBOVUxMOw0KKyNlbmRpZg0KIAltdHhfYXNzZXJ0KCZHaWFudCwgTUFf Tk9UT1dORUQpOw0KIH0NCiANCkluZGV4OiBrZXJuL3N1YnJfdHJhcC5jDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9z cmMvc3lzL2tlcm4vc3Vicl90cmFwLmMsdg0KcmV0cmlldmluZyByZXZpc2lv biAxLjIwNw0KZGlmZiAtdSAtcjEuMjA3IHN1YnJfdHJhcC5jDQotLS0ga2Vy bi9zdWJyX3RyYXAuYwkxMSBGZWIgMjAwMiAyMDozNzo1MyAtMDAwMAkxLjIw Nw0KKysrIGtlcm4vc3Vicl90cmFwLmMJMTMgRmViIDIwMDIgMDE6MDc6MTIg LTAwMDANCkBAIC01Niw2ICs1NiwyNCBAQA0KICNpbmNsdWRlIDxtYWNoaW5l L3BjYi5oPg0KIA0KIC8qDQorICogc21hbGwgcm91dGluZSB0byBzd2FwIGEg dGhyZWFkJ3MgY3VycmVudCB1Y3JlZCBmb3IgdGhlIGNvcnJlY3Qgb25lDQor ICogdGFrZW4gZnJvbSB0aGUgcHJvY2Vzcw0KKyAqLw0KK3ZvaWQNCithcXVp cmVfdWNyZWQoc3RydWN0IHRocmVhZCAqdGQsIHN0cnVjdCBwcm9jICpwKQ0K K3sNCisJaWYgKHRkLT50ZF91Y3JlZCAhPSBOVUxMKSB7DQorCQltdHhfbG9j aygmR2lhbnQpOw0KKwkJY3JmcmVlKHRkLT50ZF91Y3JlZCk7DQorCQltdHhf dW5sb2NrKCZHaWFudCk7DQorCQl0ZC0+dGRfdWNyZWQgPSBOVUxMOw0KKwl9 DQorCVBST0NfTE9DSyhwKTsNCisJdGQtPnRkX3VjcmVkID0gY3Job2xkKHAt PnBfdWNyZWQpOw0KKwlQUk9DX1VOTE9DSyhwKTsNCit9DQorDQorLyoNCiAg KiBEZWZpbmUgdGhlIGNvZGUgbmVlZGVkIGJlZm9yZSByZXR1cm5pbmcgdG8g dXNlciBtb2RlLCBmb3INCiAgKiB0cmFwIGFuZCBzeXNjYWxsLg0KICAqDQpA QCAtMTYxLDkgKzE3OSw4IEBADQogCQkJcC0+cF9zdGF0cy0+cF9wcm9mLnBy X3RpY2tzID0gMDsNCiAJCX0NCiAJCW10eF91bmxvY2tfc3Bpbigmc2NoZWRf bG9jayk7DQotCQlQUk9DX0xPQ0socCk7DQotCQl0ZC0+dGRfdWNyZWQgPSBj cmhvbGQocC0+cF91Y3JlZCk7DQotCQlQUk9DX1VOTE9DSyhwKTsNCisJCWlm ICh0ZC0+dGRfdWNyZWQgIT0gcC0+cF91Y3JlZCkgDQorCQkJYXF1aXJlX3Vj cmVkKHRkLCBwKTsNCiAJCWlmIChmbGFncyAmIEtFRl9PV0VVUEMgJiYgc2Zs YWcgJiBQU19QUk9GSUwpDQogCQkJYWRkdXBjX3Rhc2soa2UsIHAtPnBfc3Rh dHMtPnBfcHJvZi5wcl9hZGRyLCBwcnRpY2tzKTsNCiAJCWlmIChzZmxhZyAm IFBTX0FMUk1QRU5EKSB7DQpAQCAtMTg4LDEwICsyMDUsMTIgQEANCiAJCX0N CiANCiAJCXVzZXJyZXQodGQsIGZyYW1lcCwgc3RpY2tzKTsNCisjaWZkZWYJ SU5WQVJJQU5UUw0KIAkJbXR4X2xvY2soJkdpYW50KTsNCiAJCWNyZnJlZSh0 ZC0+dGRfdWNyZWQpOw0KIAkJbXR4X3VubG9jaygmR2lhbnQpOw0KIAkJdGQt PnRkX3VjcmVkID0gTlVMTDsNCisjZW5kaWYNCiAJCXMgPSBjcHVfY3JpdGlj YWxfZW50ZXIoKTsNCiAJfQ0KIAltdHhfYXNzZXJ0KCZHaWFudCwgTUFfTk9U T1dORUQpOw0KSW5kZXg6IHN5cy91Y3JlZC5oDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL3N5cy91Y3Jl ZC5oLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4yNg0KZGlmZiAtdSAtcjEu MjYgdWNyZWQuaA0KLS0tIHN5cy91Y3JlZC5oCTExIE9jdCAyMDAxIDIzOjM4 OjE3IC0wMDAwCTEuMjYNCisrKyBzeXMvdWNyZWQuaAkxMyBGZWIgMjAwMiAw MTowNzoyMiAtMDAwMA0KQEAgLTgzLDE5ICs4MywyMCBAQA0KICNpZmRlZiBf S0VSTkVMDQogDQogDQotdm9pZAkJY2hhbmdlX2VnaWQgX19QKChzdHJ1Y3Qg dWNyZWQgKm5ld2NyZWQsIGdpZF90IGVnaWQpKTsNCi12b2lkCQljaGFuZ2Vf ZXVpZCBfX1AoKHN0cnVjdCB1Y3JlZCAqbmV3Y3JlZCwgdWlkX3QgZXVpZCkp Ow0KLXZvaWQJCWNoYW5nZV9yZ2lkIF9fUCgoc3RydWN0IHVjcmVkICpuZXdj cmVkLCBnaWRfdCByZ2lkKSk7DQotdm9pZAkJY2hhbmdlX3J1aWQgX19QKChz dHJ1Y3QgdWNyZWQgKm5ld2NyZWQsIHVpZF90IHJ1aWQpKTsNCi12b2lkCQlj aGFuZ2Vfc3ZnaWQgX19QKChzdHJ1Y3QgdWNyZWQgKm5ld2NyZWQsIGdpZF90 IHN2Z2lkKSk7DQotdm9pZAkJY2hhbmdlX3N2dWlkIF9fUCgoc3RydWN0IHVj cmVkICpuZXdjcmVkLCB1aWRfdCBzdnVpZCkpOw0KLXZvaWQJCWNyY29weSBf X1AoKHN0cnVjdCB1Y3JlZCAqZGVzdCwgc3RydWN0IHVjcmVkICpzcmMpKTsN Ci1zdHJ1Y3QgdWNyZWQJKmNyZHVwIF9fUCgoc3RydWN0IHVjcmVkICpjcikp Ow0KLXZvaWQJCWNyZnJlZSBfX1AoKHN0cnVjdCB1Y3JlZCAqY3IpKTsNCi1z dHJ1Y3QgdWNyZWQJKmNyZ2V0IF9fUCgodm9pZCkpOw0KLXN0cnVjdCB1Y3Jl ZAkqY3Job2xkIF9fUCgoc3RydWN0IHVjcmVkICpjcikpOw0KLWludAkJY3Jz aGFyZWQgX19QKChzdHJ1Y3QgdWNyZWQgKmNyKSk7DQotaW50CQlncm91cG1l bWJlciBfX1AoKGdpZF90IGdpZCwgc3RydWN0IHVjcmVkICpjcmVkKSk7DQor dm9pZAkJYXF1aXJlX3VjcmVkKHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1Y3Qg cHJvYyAqcCk7DQordm9pZAkJY2hhbmdlX2VnaWQgKHN0cnVjdCB1Y3JlZCAq bmV3Y3JlZCwgZ2lkX3QgZWdpZCk7DQordm9pZAkJY2hhbmdlX2V1aWQgKHN0 cnVjdCB1Y3JlZCAqbmV3Y3JlZCwgdWlkX3QgZXVpZCk7DQordm9pZAkJY2hh bmdlX3JnaWQgKHN0cnVjdCB1Y3JlZCAqbmV3Y3JlZCwgZ2lkX3QgcmdpZCk7 DQordm9pZAkJY2hhbmdlX3J1aWQgKHN0cnVjdCB1Y3JlZCAqbmV3Y3JlZCwg dWlkX3QgcnVpZCk7DQordm9pZAkJY2hhbmdlX3N2Z2lkIChzdHJ1Y3QgdWNy ZWQgKm5ld2NyZWQsIGdpZF90IHN2Z2lkKTsNCit2b2lkCQljaGFuZ2Vfc3Z1 aWQgKHN0cnVjdCB1Y3JlZCAqbmV3Y3JlZCwgdWlkX3Qgc3Z1aWQpOw0KK3Zv aWQJCWNyY29weSAoc3RydWN0IHVjcmVkICpkZXN0LCBzdHJ1Y3QgdWNyZWQg KnNyYyk7DQorc3RydWN0IHVjcmVkCSpjcmR1cCAoc3RydWN0IHVjcmVkICpj cik7DQordm9pZAkJY3JmcmVlIChzdHJ1Y3QgdWNyZWQgKmNyKTsNCitzdHJ1 Y3QgdWNyZWQJKmNyZ2V0ICh2b2lkKTsNCitzdHJ1Y3QgdWNyZWQJKmNyaG9s ZCAoc3RydWN0IHVjcmVkICpjcik7DQoraW50CQljcnNoYXJlZCAoc3RydWN0 IHVjcmVkICpjcik7DQoraW50CQlncm91cG1lbWJlciAoZ2lkX3QgZ2lkLCBz dHJ1Y3QgdWNyZWQgKmNyZWQpOw0KICNlbmRpZiAvKiBfS0VSTkVMICovDQog DQogI2VuZGlmIC8qICFfU1lTX1VDUkVEX0hfICovDQo= --0-1508433265-1013906985=:39539-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 17:41:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 44D9B37B416; Sat, 16 Feb 2002 17:41:09 -0800 (PST) Received: from pool0237.cvx21-bradley.dialup.earthlink.net ([209.179.192.237] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16cGJq-0004kb-00; Sat, 16 Feb 2002 17:40:46 -0800 Message-ID: <3C6F0A13.258882FF@mindspring.com> Date: Sat, 16 Feb 2002 17:40:35 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Matthew Dillon , Alfred Perlstein , Poul-Henning Kamp , arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday()and copyout(). Is copyout() MPSAFE on non-i386 archs? ) References: 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 This whole cred thing on gettimeofday is silly. I was able to ensure that the contents of a copy of the timecounter context struct were rotated between two buffers with an atomic pointer update, each time they were updated. I really don't understand the need for a very large pool of these things, and I don't really understand the need for locking, so long as the pointer change is atomic, and the clock update is always handled b y a single processor. By taking this single page, two structure, area, and setting up an additional mapping, read-only, with the PG_G and PG_U bits set, the pointer can be directly dereferenced from user space, providing an accurate zero system call "gettimeofday" call (the easy part is copying the kernel space code for the structure content use to user space). With the PG_U bit set on the page, the same pointer can be used in both user and kernel space to access the snapshot structure, so there's no decoherence from the change from kernel space copy to user space dereference. Pretty simple, actually. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 17:51:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id D36A537B416 for ; Sat, 16 Feb 2002 17:51:38 -0800 (PST) Received: from madman.nectar.cc (madman.nectar.cc [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id 4B2582C; Sat, 16 Feb 2002 19:51:38 -0600 (CST) Received: (from nectar@localhost) by madman.nectar.cc (8.11.6/8.11.6) id g1H1pZA46896; Sat, 16 Feb 2002 19:51:35 -0600 (CST) (envelope-from nectar) Date: Sat, 16 Feb 2002 19:51:35 -0600 From: "Jacques A. Vidrine" To: "J. Mallett" Cc: freebsd-arch@freebsd.org Subject: Re: Generalisation of Base64 function prototypes. Message-ID: <20020217015135.GA46829@madman.nectar.cc> Mail-Followup-To: "Jacques A. Vidrine" , "J. Mallett" , freebsd-arch@freebsd.org References: <20020216030032.A12929@NewGold.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020216030032.A12929@NewGold.NET> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ 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 Just a couple'o'comments: On Sat, Feb 16, 2002 at 03:00:33AM +0000, J. Mallett wrote: > Hello, > I've been working on base64 ala MIME support for uudecode(1) and > uuencode(1), as part of standards conformance projects. Rather than > re-implement base64 stuff inline, I looked high and low for base64 > functions in libc. Please see also src/lib/roken/base64.h and src/lib/roken/base64.c. These are part of Heimdal Kerberos. libroken is currently installed in /usr/lib, but the base64.h header file is not. > Except of course, what I proposed above the prototypes > and preprocessor definitions I so hastily inserted, and that is moving > b64_* stuff from to . IMHO this kind of thing doesn't belong in . If it is to be made a general facility, I think a seperate header file is what is called for. libroken is meant to be a kitchen sink. I don't think libc should, but it is. In the future, we will probably not install libroken at all --- just use it during the build of the Kerberos bits. Cheers, -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 18:52: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id B8BE537B402 for ; Sat, 16 Feb 2002 18:51:56 -0800 (PST) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020217025156.MMNA2626.rwcrmhc51.attbi.com@gateway.posi.net>; Sun, 17 Feb 2002 02:51:56 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g1H2psY62194; Sat, 16 Feb 2002 18:51:55 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Sat, 16 Feb 2002 18:51:54 -0800 (PST) From: Kelly Yancey To: "Jacques A. Vidrine" Cc: "J. Mallett" , Subject: Re: Generalisation of Base64 function prototypes. In-Reply-To: <20020217015135.GA46829@madman.nectar.cc> Message-ID: <20020216185112.E62177-100000@gateway.posi.net> 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, 16 Feb 2002, Jacques A. Vidrine wrote: > Just a couple'o'comments: > > On Sat, Feb 16, 2002 at 03:00:33AM +0000, J. Mallett wrote: > > Hello, > > I've been working on base64 ala MIME support for uudecode(1) and > > uuencode(1), as part of standards conformance projects. Rather than > > re-implement base64 stuff inline, I looked high and low for base64 > > functions in libc. > > Please see also src/lib/roken/base64.h and src/lib/roken/base64.c. > These are part of Heimdal Kerberos. libroken is currently installed > in /usr/lib, but the base64.h header file is not. > > > Except of course, what I proposed above the prototypes > > and preprocessor definitions I so hastily inserted, and that is moving > > b64_* stuff from to . > > IMHO this kind of thing doesn't belong in . If it is to be > made a general facility, I think a seperate header file is what is > called for. > > libroken is meant to be a kitchen sink. I don't think libc should, > but it is. In the future, we will probably not install libroken at > all --- just use it during the build of the Kerberos bits. > > Cheers, > -- > Jacques A. Vidrine http://www.nectar.cc/ libutil? Kelly kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 22:32:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 21D7C37B405; Sat, 16 Feb 2002 22:32:24 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1H6WGt43386; Sat, 16 Feb 2002 22:32:16 -0800 (PST) (envelope-from dillon) Date: Sat, 16 Feb 2002 22:32:16 -0800 (PST) From: Matthew Dillon Message-Id: <200202170632.g1H6WGt43386@apollo.backplane.com> To: Terry Lambert Cc: Julian Elischer , Alfred Perlstein , Poul-Henning Kamp , arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday()and copyout(). Is copyout() MPSAFE on non-i386 archs? ) References: <3C6F0A13.258882FF@mindspring.com> 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 Well, this is really more of a side-converstaion, but in general I agree. Still, if we construct a global userspace-accessible page we have to be *very* careful about future backwards compatibility. Consider what would have happened if, say, BSDI used this trick and we had to support it in our emulation code? Or Linux, or NetBSD, etc... So, I'm all for it, as long as we do it right: Have a system call that returns the address of specific elements of the shared page. e.g. something like: time_t *t = system_pointer(SYSPTR_TIME_32); libc could store it in a global and should be able to handle a SYSPTR_BAD return (meaning that the requested entity is not supported as a shared memory variable, for example due to being too large for atomic access and to make emulation easier). This also gives us flexibility in regards to where and when the page is mapped. Here is a quick example (assuming no user-level sysinit mechanism): time_t libc_time(time_t *t) { static time_t *tptr; if (tptr == NULL) tptr = system_pointer(SYSPTR_TIME_32); else if (tptr != SYSPTR_BAD) *t = *tptr; else *t = time(NULL); return(*t); } Something like this would be trivial to emulate (one just makes the system call always return SYSPTR_BAD) in a compatible way and we wouldn't have to worry about structural position changes. -Matt Matthew Dillon :This whole cred thing on gettimeofday is silly. : :I was able to ensure that the contents of a copy of the :timecounter context struct were rotated between two :buffers with an atomic pointer update, each time they :were updated. : :I really don't understand the need for a very large :pool of these things, and I don't really understand :the need for locking, so long as the pointer change :is atomic, and the clock update is always handled b y :a single processor. : :By taking this single page, two structure, area, and :setting up an additional mapping, read-only, with :the PG_G and PG_U bits set, the pointer can be :directly dereferenced from user space, providing an :accurate zero system call "gettimeofday" call (the :easy part is copying the kernel space code for the :structure content use to user space). : :With the PG_U bit set on the page, the same pointer :can be used in both user and kernel space to access :the snapshot structure, so there's no decoherence :from the change from kernel space copy to user space :dereference. : :Pretty simple, actually. : :-- Terry : :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 Sat Feb 16 22:42: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7414C37B404; Sat, 16 Feb 2002 22:42:02 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1H6fRb43456; Sat, 16 Feb 2002 22:41:27 -0800 (PST) (envelope-from dillon) Date: Sat, 16 Feb 2002 22:41:27 -0800 (PST) From: Matthew Dillon Message-Id: <200202170641.g1H6fRb43456@apollo.backplane.com> To: Julian Elischer Cc: Alfred Perlstein , Poul-Henning Kamp , arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday() and copyout(). Is copyout() MPSAFE on non-i386 archs? ) References: 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 :the whole point is moot.. :you don't need to get or drop the creds at all.. : :see the attached patch I'm about to commit a version of.. I like it in general, but I don't like INVARIANTS causing so much grief in the SMP path. If the whole point is to not drop the ucred in the syscall then we shouldn't drop it whether INVARIANTS is set or not. I would like to see the invariants sections simply removed. I like to run with INVARIANTS set, even on production systems, because I like the extra assertions it makes. In anycase, I am going to go ahead and commit the mutex pool part of my patch to cut down on the size of the ucred structure. Then I'm going to go through and see if we do any other messing around with credentials (like in the NFS code) to determine if removing Giant is still necessary. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 23: 0:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id BAF0137B404; Sat, 16 Feb 2002 23:00:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020217070010.WCPO1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Sun, 17 Feb 2002 07:00:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA44493; Sat, 16 Feb 2002 22:54:52 -0800 (PST) Message-Id: <200202170654.WAA44493@InterJet.elischer.org> Date: Sat, 16 Feb 2002 22:54:51 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: Alfred Perlstein , Poul-Henning Kamp , arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday() 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 and copyout(). Is copyout() MPSAFE on non-i386 archs? ) In-Reply-To: <200202170641.g1H6fRb43456@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 16 Feb 2002, Matthew Dillon wrote: > > :the whole point is moot.. > :you don't need to get or drop the creds at all.. > : > :see the attached patch I'm about to commit a version of.. > > I like it in general, but I don't like INVARIANTS causing so much grief > in the SMP path. If the whole point is to not drop the ucred in the > syscall then we shouldn't drop it whether INVARIANTS is set or not. > I would like to see the invariants sections simply removed. > > I like to run with INVARIANTS set, even on production systems, because > I like the extra assertions it makes. I agree but jhb wants to have it that way... He wants to be able to catch anyone accessing the ucred of a thread that is in user space. I personally think we should just remove the code. > > In anycase, I am going to go ahead and commit the mutex pool part of > my patch to cut down on the size of the ucred structure. Then I'm going > to go through and see if we do any other messing around with credentials > (like in the NFS code) to determine if removing Giant is still necessary. > > -Matt > > > 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 Sat Feb 16 23:13:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C766137B405; Sat, 16 Feb 2002 23:13:31 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1H7Cxb48783; Sat, 16 Feb 2002 23:12:59 -0800 (PST) (envelope-from dillon) Date: Sat, 16 Feb 2002 23:12:59 -0800 (PST) From: Matthew Dillon Message-Id: <200202170712.g1H7Cxb48783@apollo.backplane.com> To: Julian Elischer Cc: Alfred Perlstein , Poul-Henning Kamp , arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday() References: <200202170654.WAA44493@InterJet.elischer.org> 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 agree but jhb wants to have it that way... He wants to be able to catch :anyone accessing the ucred of a thread that is in user space. I :personally think we should just remove the code. It makes it rather difficult to work on the Giant pushdown code because it's going to catch a majority of process blockages, making it difficult for us to guage the effect of our Giant pushdown work and also making it difficult to track down what Giant locks are still being obtained. If John (John?) is going to insist on leaving that code in, then I will have to commit the Giant-less crfree() code pretty much now to get around the deficiency. Now, it may wind up being a good idea to have giant-less crfree() code anyway, since crfree() is called from the VM system (and NFS, and the file descriptor code, and the VFS subsystem, and a few other places deep in the code). It will be rather difficult to get Giant pushed down into those subsystems without fixing crfree() anyway, but the work isn't likely to progress that far for a few weeks or a month or two depending. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 16 23:29: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1460137B400; Sat, 16 Feb 2002 23:29:04 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1H7SV651230; Sat, 16 Feb 2002 23:28:31 -0800 (PST) (envelope-from dillon) Date: Sat, 16 Feb 2002 23:28:31 -0800 (PST) From: Matthew Dillon Message-Id: <200202170728.g1H7SV651230@apollo.backplane.com> To: Julian Elischer Cc: Alfred Perlstein , Poul-Henning Kamp , arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday() References: <200202170654.WAA44493@InterJet.elischer.org> 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 would like to see the invariants sections simply removed. :> :> I like to run with INVARIANTS set, even on production systems, because :> I like the extra assertions it makes. : :I agree but jhb wants to have it that way... He wants to be able to catch :anyone accessing the ucred of a thread that is in user space. I :personally think we should just remove the code. Another problem with this is that most -current developers are (I assume) running with INVARIANTS (because they'd be fools not to). This means that the code you just comitted is not going to be exercised at all due to the crfree()'s. --- In anycase, your code plus #if 0'ing the INVARIANTS and the KASSERT's that were checking td_ucred == NULL results in a significant improvement in syscall performance. I am now getting: CURRENT 2xCPU SMP BUILD W/Julian's code and ucred invariants blasted to bits and Matt's mutex pool code and removal of Giant for gettimeofday(). one TG running: 462478/sec two TGs running: 361962/sec per TG prior tests: CURRENT 2xCPU SMP BUILD Original gettimeofday() code one TG running: 350000/sec two TGs running: 55000/sec per TG (no, that isn't a type-o) CURRENT 2xCPU SMP BUILD W/Giant removed from gettimeofday() one TG running: 375000/sec two TGs running: 301000/sec per TG (due to ucred Giant issues) CURRENT, gettimeofday() SMP patch, Matt's original ucred patch: 1 TG running: 396365 calls/sec 2 TGs running: 322000 calls/sec each. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 17 0: 0:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id A3CEF37B404; Sun, 17 Feb 2002 00:00:16 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020217080016.VXYF2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Sun, 17 Feb 2002 08:00:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA44708; Sat, 16 Feb 2002 23:56:14 -0800 (PST) Date: Sat, 16 Feb 2002 23:56:13 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: Alfred Perlstein , Poul-Henning Kamp , arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday() In-Reply-To: <200202170712.g1H7Cxb48783@apollo.backplane.com> 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 either way, could you do you timing tests on a NON-INVARIANT kernel to judge the difference this makes? In the mean while, John, is it really necessary to have this there? I can remove it (and the KASSERTS) in a flash if you'll let me... On Sat, 16 Feb 2002, Matthew Dillon wrote: > : > :I agree but jhb wants to have it that way... He wants to be able to catch > :anyone accessing the ucred of a thread that is in user space. I > :personally think we should just remove the code. > > It makes it rather difficult to work on the Giant pushdown code because > it's going to catch a majority of process blockages, making it difficult > for us to guage the effect of our Giant pushdown work and also making > it difficult to track down what Giant locks are still being obtained. > If John (John?) is going to insist on leaving that code in, then I will > have to commit the Giant-less crfree() code pretty much now to get > around the deficiency. > > Now, it may wind up being a good idea to have giant-less crfree() code > anyway, since crfree() is called from the VM system (and NFS, and the > file descriptor code, and the VFS subsystem, and a few other places > deep in the code). It will be rather difficult to get Giant pushed > down into those subsystems without fixing crfree() anyway, but the work > isn't likely to progress that far for a few weeks or a month or two > depending. > > -Matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message