From owner-freebsd-arch Sun Apr 8 0:54:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3979937B424 for ; Sun, 8 Apr 2001 00:54:16 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA11566; Sun, 8 Apr 2001 17:52:51 +1000 Date: Sun, 8 Apr 2001 17:50:54 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Greg Lehey Cc: FreeBSD-arch@FreeBSD.ORG Subject: Re: Making ddb a kld In-Reply-To: <20010408113054.L76422@wantadilla.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 8 Apr 2001, Greg Lehey wrote: > >> 1. We often get people who say "my system crashes. Why". On > >> checking, there's no practical way to determine why, because they > >> don't have a debugger in the system. > > > > They can run gdb if they have a panic dump. > > If they have a panic dump and a kernel with symbols. You'll recall > that all attempts of mine to get the latter as default have been shot > down in flames. All kernels have symbols (non-debugging ones, the same that ddb has). > Consider following scenario, on a production machine. Machine works > fine for months, then starts crashing. Remote support dials in, loads > the ddb module into the running system, then waits. When the machine > crashes, remote support dials in again and debugs via serial > interface. > > Not the best way to do things, admittedly, but one that some people > like to do. To quote one respected member of our community: Remote support dials in, builds a kernel with ddb and possibly other debugging code configured, and reboots to the new kernel (or just install it and wait for a crash to reboot to it). > > I normally use ddb anyway -- gdb takes too long to start up and > > doesn't work well for low-level stuff. > > >> 2. Occasionally it's convenient to look at what's happening in a > >> running system. Admittedly, you have to freeze the system to use > >> ddb, but it can be of use. > > > > Again, it is better to always configure ddb, in case you need it to > > look at what's happening on a hung system that can't load a module. > > Then we should make it part of the default kernel. But there will > always be cases where one particular debugging method doesn't work. > That doesn't disqualify it completely as a method. It would just be bloat and a security hole for most people. > >> Con: > >> > >> 1. This will require moving all the ddb code, which is scattered > >> around the system, into a separate file. I'm prepared to do the > > Version mismatch problems are another issue, one which we should > address. They don't belong in this discussion. But I thought that > ddb would recover from that kind of error, just as it does if you try > to display the contents of unmapped memory. I had forgotten about that. Yes, it should recover, provided ddb doesn't use any locks (longjmp'ing out of the trap handler would leave the locks active). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Apr 8 17:18:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 6BB0D37B422 for ; Sun, 8 Apr 2001 17:18:25 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f390IOs04689 for ; Sun, 8 Apr 2001 18:18:25 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200104090018.f390IOs04689@aslan.scsiguy.com> To: arch@FreeBSD.org Subject: Inheritance in new-bus Date: Sun, 08 Apr 2001 18:18:24 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I decided to play around with this again. So far I have a system that allows inheritance of "interfaces" in new-bus. This means that cardbus, for instance, can inherit bus, device and pci interfaces from the PCI code, and CIS parsing fuctions from pccard. Each kobject has an array of interfaces. Each interface includes a parent interface pointer. To subscribe to an interface, a kobject need only list the interface in its list of interfaces. To override methods of an interface, a new interface is defined with a list of methods and a pointer to the parent interface. A "root" interface uses "null_interface" as its parent. The upshot of this is that, so long as a sub-interface does not need to explicitly call the parent interface's implementation of method as part of its own implementation of the method, there is no need to know anything about the parents implementation. The hierarchy of methods also removes the need for the defop method in a method description - the root interface is the default. I'd like to be able to opaquely call the "parent" implementation of method from a method override, but I haven't found a scheme I'm totally happy with. The best I have so far would require KOBJMETHOD declarations outside of the method array so each method within a file can be referenced by symbol name. The method array would then become an array of pointers to methods. The perl scripts would then be responsible for making macros to do the appropriate casting to call the parent method stored in the method descripter. The parent would be filled in during class compilation. Patches sufficient to get my laptop to run can be found here: http://people.FreeBSD.org/~gibbs/newbus_pci_cardbus.diffs Some of the changes can be simplified as some interface users do not perform overrides and I neglected to just reference the interface directly. There are also lots of pieces of code that might benefit from a rewrite to make use of this new feature. Comments? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Apr 8 20:43:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 5E36C37B423 for ; Sun, 8 Apr 2001 20:43:13 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=d78a7583ac2967978b5e8c0c8950bf04) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14mSa8-0000GS-00 for arch@FreeBSD.ORG; Sun, 08 Apr 2001 21:43:12 -0600 Message-ID: <3AD12FCF.BA652E1F@softweyr.com> Date: Sun, 08 Apr 2001 21:43:12 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@FreeBSD.ORG Subject: Re: Startup scripts a la NetBSD References: <3AC9F003.85901B0B@softweyr.com> <20010406022605.A17550@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > On Tue, Apr 03, 2001 at 09:45:07AM -0600, Wes Peters wrote: > > Must discussion has ensued over how to actually solve this problem, instead > > of leaving it to the system administrator to magically conjure up what the > > dependencies are then hack in the correct order of Sxxx and Kxxx BS to make > > it work. If you have a solution, we're ready to see and test it. > > NetBSD has a solution. Thank you, I'll be downloading 1.5 at work tomorrow. Or maybe here tonight; I've got a spare x86 machine at the moment. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 9 12: 7:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id C868A37B424 for ; Mon, 9 Apr 2001 12:07:47 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id MAA01025; Mon, 9 Apr 2001 12:06:14 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpdAAADQayUb; Mon Apr 9 12:05:59 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA27205; Mon, 9 Apr 2001 12:07:29 -0700 (MST) From: Terry Lambert Message-Id: <200104091907.MAA27205@usr08.primenet.com> Subject: Re: Making ddb a kld To: grog@lemis.com (Greg Lehey) Date: Mon, 9 Apr 2001 19:07:29 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), FreeBSD-arch@FreeBSD.ORG In-Reply-To: <20010407104709.B24010@wantadilla.lemis.com> from "Greg Lehey" at Apr 07, 2001 10:47:09 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> 1. This will require moving all the ddb code, which is scattered > >> around the system, into a separate file. I'm prepared to do the > >> work, but it's possible that somebody would complain about the > >> colour of the bikeshed. Here's your chance. > > > > How does it deal with the locore.s issues? > > Which locore.s issues? BDE's debugger hooks in multiple places in locore.s, both for the signature compare for startup, and for bdb_prepare_paging() and bdb_commit_paging() to permit tracing through initi386(). It also changes the kernel text mapping from read-only to read/write, as well as hooking the debugging trap in the IDT, very early on. I don't see how you could do several of these things in a loadable module, unless you pretended it was always loaded (and eat the IDT and other overhead). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 9 12:13: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id B2FBB37B422; Mon, 9 Apr 2001 12:13:01 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id MAA17703; Mon, 9 Apr 2001 12:12:40 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAAQ9aGCI; Mon Apr 9 12:12:33 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA27312; Mon, 9 Apr 2001 12:12:42 -0700 (MST) From: Terry Lambert Message-Id: <200104091912.MAA27312@usr08.primenet.com> Subject: Re: Eliminate crget() from nfs kernel code? To: rwatson@FreeBSD.ORG (Robert Watson) Date: Mon, 9 Apr 2001 19:12:41 +0000 (GMT) Cc: dillon@earth.backplane.com (Matt Dillon), tlambert@primenet.com (Terry Lambert), freebsd-arch@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Apr 06, 2001 09:53:32 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ok, I've committed a change to 5.0-CURRENT to move to simply using the > p->p_ucred rather than constructing a ucred using crget(). I've interop'd > with Solaris and FreeBSD NFS servers, and it seemed to work fine. I'd > appreciate it if others could do testing -- the primary test is simply > whether "df /your/nfs/mount" running as non-root DTRT. I haven't had a > chance yet, but sometime in the next day or two I'll get out and RPC > dumper (dunno if tcpdump knows how to do this, maybe snoop from Solaris > does) and look at the credentials used for NFSPROC_STATFS requests > generated by other implementations. Chances are, if another already uses > normal non-uid-0 non-gid-0 credentials, then we're safe. Specifically, this should be tested for interoperability with AIX NFS, which can be pissy about credentials which don't exist locally. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 9 13: 5:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 2247437B423; Mon, 9 Apr 2001 13:05:11 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f39K41G26887; Mon, 9 Apr 2001 13:04:01 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200104062308.QAA05544@usr01.primenet.com> Date: Mon, 09 Apr 2001 13:04:34 -0700 (PDT) From: John Baldwin To: Terry Lambert Subject: Re: Eliminate crget() from nfs kernel code? Cc: freebsd-arch@FreeBSD.org, (Matt Dillon) , (Robert Watson) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 06-Apr-01 Terry Lambert wrote: >> make the NFS RPC with an existing credential > > instantiate a credential > make the NFS RPC > > > > free the credential > >> into the implementation, and it is valid for the durection of the function >> call. If the NFS implementation needs to preserve the credential, it will >> do so by bumping the reference count. > > It was not clear to me from a casual perusal of the code whether > or not holding a reference to a credential used by a process would > keep it from going away, or if it always went away on the 1->0 > decrement. Geez, that must've been _real_ casual, Terry. :) /* * Free a cred structure. * Throws away space when ref count gets to 0. */ void crfree(cr) struct ucred *cr; { mtx_lock(&cr->cr_mtx); if (--cr->cr_ref == 0) { mtx_destroy(&cr->cr_mtx); .... FREE((caddr_t)cr, M_CRED); } else { mtx_unlock(&cr->cr_mtx); } } Come on, even the comment indicates that it does that. :) > It seems to me that credential instantiation becomes a problem, and > it also seems to me that this is what you are trying to fix with > your changes elsewhere. > > Eventually, the credential has to come from somewhere, and to come > from somewhere, it has to be allocated. Erm, have you worked with refcount'd things before? :-P We malloc a new copy in crdup() (which can be called by crcopy if needed) and we only free when the refcount goes to zero. By bumping the refcount around the RPC, the cred stays valid until the crfree() after the RPC returns, even if the process terminates and goes away. Really, this isn't rocket science. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 9 13: 5:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id B2E0937B62C for ; Mon, 9 Apr 2001 13:05:25 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f39K42G26891; Mon, 9 Apr 2001 13:04:02 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010408113054.L76422@wantadilla.lemis.com> Date: Mon, 09 Apr 2001 13:04:34 -0700 (PDT) From: John Baldwin To: Greg Lehey Subject: Re: Making ddb a kld Cc: FreeBSD-arch@FreeBSD.org, Bruce Evans Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 08-Apr-01 Greg Lehey wrote: > On Saturday, 7 April 2001 at 17:37:27 +1000, Bruce Evans wrote: >> On Fri, 6 Apr 2001, Greg Lehey wrote: >> >>> A little over a year, I did some work for Sitara Networks. In the >>> course of this work, I made ddb an lkm, in order to be able to load it >>> on a production system if needed. >>> >>> I'm now in the process of merging Sitara's code, which is based on >>> 3.2-RELEASE, into RELENG_4. Sitara have generously agreed that we can >>> commit any fixes they have in their tree which are not vital to their >>> commercial interests. The ddb mods would be one of them. Do we want >>> to do this? >> >> Of course not. >> >>> The pros and cons I see are: >>> >>> Pro: >>> >>> 1. We often get people who say "my system crashes. Why". On >>> checking, there's no practical way to determine why, because they >>> don't have a debugger in the system. >> >> They can run gdb if they have a panic dump. > > If they have a panic dump and a kernel with symbols. You'll recall > that all attempts of mine to get the latter as default have been shot > down in flames. Oh geez. www.freebsd.org/~jhb/patches/newkern.patch for current. I just haven't tested to make sure that hte alpha CD still boots ok with the mfsroot changes. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 9 15:44:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id AE09937B42C; Mon, 9 Apr 2001 15:44:52 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id PAA23838; Mon, 9 Apr 2001 15:44:51 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAAsCaOFU; Mon Apr 9 15:44:46 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA02241; Mon, 9 Apr 2001 15:44:48 -0700 (MST) From: Terry Lambert Message-Id: <200104092244.PAA02241@usr08.primenet.com> Subject: Re: Eliminate crget() from nfs kernel code? To: jhb@FreeBSD.org (John Baldwin) Date: Mon, 9 Apr 2001 22:44:48 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), freebsd-arch@FreeBSD.org, dillon@earth.backplane.com ((Matt Dillon)), rwatson@FreeBSD.org ((Robert Watson)) In-Reply-To: from "John Baldwin" at Apr 09, 2001 01:04:34 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> make the NFS RPC with an existing credential > > > > instantiate a credential > > make the NFS RPC > > > > > > > > free the credential > > > >> into the implementation, and it is valid for the durection of the function > >> call. If the NFS implementation needs to preserve the credential, it will > >> do so by bumping the reference count. > > > > It was not clear to me from a casual perusal of the code whether > > or not holding a reference to a credential used by a process would > > keep it from going away, or if it always went away on the 1->0 > > decrement. > > Geez, that must've been _real_ casual, Terry. :) Maybe I was too opaque in my statement? By "reference", I did not mean an increment of cr_ref. Looking at the code less casually, it seems to always go away on the 1->0 decrement. I can imagine cases where the NFS reference becomes the only remaining reference for the credential. I think that that is a Bad Thing, since NFS outages can live drastically longer than the referencing process that gave it the credential. I can imagine a bunch of orphan credentials piling up in the NFS code, waiting for the RPC to come back from a dead server. > > It seems to me that credential instantiation becomes a problem, and > > it also seems to me that this is what you are trying to fix with > > your changes elsewhere. > > > > Eventually, the credential has to come from somewhere, and to come > > from somewhere, it has to be allocated. > > Erm, have you worked with refcount'd things before? :-P We malloc a new > copy in crdup() (which can be called by crcopy if needed) and we only free when > the refcount goes to zero. By bumping the refcount around the RPC, the cred > stays valid until the crfree() after the RPC returns, even if the process > terminates and goes away. Really, this isn't rocket science. I think we are talking past each other. See my oprhan credential comment, above. I also don't think getting rid of crget() is going to "save the world". My complaint was that there is not a 1:1 correspondance between credentials and sessions (or all my processes would point to the same credential, and I would not need to have seperate per process authentications to get the extra credential data for things like SMB client FSs, etc.). The changed behaviour means I can't easily have that in the future. It makes session management a pain in the neck, and just that much harder to implement. I think that for the NFS case, the best thing to do would be to create a persistant "root" credential, and pass that, instead. Doing anything else is likely to break somewhere, even if FreeBSD never implements client cacheing (NFSv3 permits it over the lifetime of a lease; NFSv4 practically demands it to get the best performance). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 9 16: 0:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 4AA4437B423; Mon, 9 Apr 2001 16:00:26 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f39MxEG32038; Mon, 9 Apr 2001 15:59:14 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200104092244.PAA02241@usr08.primenet.com> Date: Mon, 09 Apr 2001 15:59:49 -0700 (PDT) From: John Baldwin To: Terry Lambert Subject: Re: Eliminate crget() from nfs kernel code? Cc: ((Robert Watson)) Cc: ((Robert Watson)) , ((Matt Dillon)) , freebsd-arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 09-Apr-01 Terry Lambert wrote: >> >> make the NFS RPC with an existing credential >> > >> > instantiate a credential >> > make the NFS RPC >> > >> > >> > >> > free the credential >> > >> >> into the implementation, and it is valid for the durection of the >> >> function >> >> call. If the NFS implementation needs to preserve the credential, it >> >> will >> >> do so by bumping the reference count. >> > >> > It was not clear to me from a casual perusal of the code whether >> > or not holding a reference to a credential used by a process would >> > keep it from going away, or if it always went away on the 1->0 >> > decrement. >> >> Geez, that must've been _real_ casual, Terry. :) > > Maybe I was too opaque in my statement? > > By "reference", I did not mean an increment of cr_ref. Well, I'm not sure how else one holds a reference, but ok. > Looking at the code less casually, it seems to always go away on the > 1->0 decrement. Yes. > I can imagine cases where the NFS reference becomes the only > remaining reference for the credential. > > I think that that is a Bad Thing, since NFS outages can live > drastically longer than the referencing process that gave it > the credential. > > I can imagine a bunch of orphan credentials piling up in the > NFS code, waiting for the RPC to come back from a dead server. Ok, however, with the current crget() code, we would have even more of these lying around. At least by using p->p_ucred, processes that share the same ucred will use the same ucred's in NFS. The proposed change will result in _fewer_ credentials piling up in this case than just creating a new ucred for each call. > My complaint was that there is not a 1:1 correspondance between > credentials and sessions (or all my processes would point to the > same credential, and I would not need to have seperate per process > authentications to get the extra credential data for things like > SMB client FSs, etc.). The changed behaviour means I can't easily > have that in the future. It makes session management a pain in > the neck, and just that much harder to implement. Actually, assuming none of your processes are setuid, they will all point to the same credential. In fork() we simply bump the refcount on the ucred, we don't actually duplicate it into another ucred. > I think that for the NFS case, the best thing to do would be to > create a persistant "root" credential, and pass that, instead. So long as this doesn't give out extra privilege. > Doing anything else is likely to break somewhere, even if FreeBSD > never implements client cacheing (NFSv3 permits it over the lifetime > of a lease; NFSv4 practically demands it to get the best performance). I fail to see why using the actual credential from the requesting process instead of blindly granting root privileges will break client caching. If anything, I'm inclined to view it the other way around, but that's just me. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 9 17:51:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 0F07137B42C; Mon, 9 Apr 2001 17:51:47 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id RAA16328; Mon, 9 Apr 2001 17:51:41 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp05.primenet.com, id smtpdAAAOyaaXF; Mon Apr 9 17:51:28 2001 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id RAA25363; Mon, 9 Apr 2001 17:51:32 -0700 (MST) From: Terry Lambert Message-Id: <200104100051.RAA25363@usr01.primenet.com> Subject: Re: Eliminate crget() from nfs kernel code? To: jhb@FreeBSD.org (John Baldwin) Date: Tue, 10 Apr 2001 00:51:31 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), rwatson@FreeBSD.org (((Robert Watson))), dillon@earth.backplane.com (((Matt Dillon))), freebsd-arch@FreeBSD.org In-Reply-To: from "John Baldwin" at Apr 09, 2001 03:59:49 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I think that for the NFS case, the best thing to do would be to > > create a persistant "root" credential, and pass that, instead. > > So long as this doesn't give out extra privilege. Of course, you would need to re-mask locally. > > Doing anything else is likely to break somewhere, even if FreeBSD > > never implements client cacheing (NFSv3 permits it over the lifetime > > of a lease; NFSv4 practically demands it to get the best performance). > > I fail to see why using the actual credential from the requesting process > instead of blindly granting root privileges will break client caching. If > anything, I'm inclined to view it the other way around, but that's just me. Because you may be denied access, while I am not denied access, so cacheing the answer is the wrong thing to do. What you really want to cache is the stat information, which can then be checked against your credential locally. To do that, you have to have the necessary rights to get the stat information. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Apr 10 16:52:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 0DD3137B423 for ; Tue, 10 Apr 2001 16:52:42 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id JAA10464 for ; Wed, 11 Apr 2001 09:52:38 +1000 (EST) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01K29PDIRZBKS4N4IK@cim.alcatel.com.au> for freebsd-arch@freebsd.org; Wed, 11 Apr 2001 09:52:27 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f3ANqYH89314 for freebsd-arch@freebsd.org; Wed, 11 Apr 2001 09:52:34 +1000 (EST envelope-from jeremyp) Content-return: prohibited Date: Wed, 11 Apr 2001 09:52:33 +1000 From: Peter Jeremy Subject: mmap(2) vs read(2)/write(2) To: freebsd-arch@freebsd.org Mail-Followup-To: freebsd-arch@freebsd.org Message-id: <20010411095233.P66243@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It is my understanding that it is more efficient to access a file via mmap rather than read/write, because the former needs one less memory-memory copy. Currently stdio uses read/write, but it would seem trivial to change at least the read operations to use mmap. For an mmap'd file, FILE->_p would point to the mmap'd region and FILE->_r would represent the number of remaining valid bytes. FILE->_bf could be used to cache the mmap'd region. My reading of ISO-C is that the mode argument to fopen(3) can include arbitrary, implementation-defined enhancements - which would allow an application to select read/write or mmap and maybe allow the application to advise its intended behaviour (ala madvise(2)). The behaviour of `portable' applications could be controlled via /etc/stdio.conf and STDIO_CONF in the same manner as malloc(3). Does this sound like a worthwhile enhancement? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Apr 10 17:15:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 6733137B422 for ; Tue, 10 Apr 2001 17:15:26 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3B0FMC11867; Tue, 10 Apr 2001 17:15:22 -0700 (PDT) Date: Tue, 10 Apr 2001 17:15:22 -0700 From: Alfred Perlstein To: Peter Jeremy Cc: freebsd-arch@FreeBSD.ORG Subject: Re: mmap(2) vs read(2)/write(2) Message-ID: <20010410171522.H15938@fw.wintelcom.net> References: <20010411095233.P66243@gsmx07.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010411095233.P66243@gsmx07.alcatel.com.au>; from peter.jeremy@alcatel.com.au on Wed, Apr 11, 2001 at 09:52:33AM +1000 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Peter Jeremy [010410 16:52] wrote: > It is my understanding that it is more efficient to access a file > via mmap rather than read/write, because the former needs one less > memory-memory copy. > > Currently stdio uses read/write, but it would seem trivial to > change at least the read operations to use mmap. For an mmap'd > file, FILE->_p would point to the mmap'd region and FILE->_r > would represent the number of remaining valid bytes. FILE->_bf > could be used to cache the mmap'd region. > > My reading of ISO-C is that the mode argument to fopen(3) can > include arbitrary, implementation-defined enhancements - which > would allow an application to select read/write or mmap and > maybe allow the application to advise its intended behaviour > (ala madvise(2)). The behaviour of `portable' applications > could be controlled via /etc/stdio.conf and STDIO_CONF in the > same manner as malloc(3). > > Does this sound like a worthwhile enhancement? Peter, the stdio would still have to copy the data into the user supplied buffer, sure you would save a context switch, but you'd have the vm overhead of constantly mapping pages in and out. I don't think it's worth it, but it shouldn't discourage you from trying and posting results. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Apr 10 19:35:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 4363937B422 for ; Tue, 10 Apr 2001 19:35:00 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3B2Ysj97756; Tue, 10 Apr 2001 19:34:54 -0700 (PDT) (envelope-from dillon) Date: Tue, 10 Apr 2001 19:34:54 -0700 (PDT) From: Matt Dillon Message-Id: <200104110234.f3B2Ysj97756@earth.backplane.com> To: Peter Jeremy Cc: freebsd-arch@FreeBSD.ORG Subject: Re: mmap(2) vs read(2)/write(2) References: <20010411095233.P66243@gsmx07.alcatel.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :It is my understanding that it is more efficient to access a file :via mmap rather than read/write, because the former needs one less :memory-memory copy. Yes and No. If the file is already in the cache, then mmap() is much faster because the program doesn't have to take any VM faults to access the data. But if the file is not in the cache the program winds up taking VM faults to map the pages in, and this is expensive enough that it goes a long ways towards making up for the copy overhead you would get with read(). This can be demonstrated with a test program. Create two test files, test1 and test2 using dd. One should be much larger then main memory, the other should be about 1/4 main memory. Run the program a couple of times before recording the results so prior runs or cache state does not interfere with the test results. Here is an example: # this assumes you have around 128M of ram dd if=/dev/zero of=test1 bs=1m count=1024 # create 1G file dd if=/dev/zero of=test1 bs=1m count=32 # create 32M file % ./rf -f test1 % ./rf -f test1 % ./rf -f test1 cksum 0 read 1073741824 bytes in 41.311 seconds, 24.788 MB/sec cpu 15.167 sec % ./rf -m test1 % ./rf -m test1 % ./rf -m test1 cksum 0 read 1073741824 bytes in 48.371 seconds, 21.170 MB/sec cpu 12.130 sec % ./rf -f test2 % ./rf -f test2 % ./rf -f test2 cksum 0 read 33554432 bytes in 0.367 seconds, 87.295 MB/sec cpu 0.368 sec % ./rf -m test2 % ./rf -m test2 % ./rf -m test2 cksum 0 read 33554432 bytes in 0.271 seconds, 117.958 MB/sec cpu 0.273 sec For the big file mmap() has lower performance (21.1MB/sec verses 24.7MB/sec), but actually eats fewer cpu cycles. In this case it is obvious that read() has a higher copy overhead, but the overhead is not interfering with the transfer rate. mmap()'s VM fault overhead, on the otherhand, is interfering with the transfer rate. It might be possible for me to fix this -- it has to do with the way VM fault does lookahead reads (it doesn't start the next lookahead read until it gets half way through the previous lookahead read). But the jist is that if the data is not in the cache, read() could very well be faster then mmap(). For the small file, mmap() wins hands down. (118MB/sec vs 87MB/sec), and takes less cpu as well (0.273 verses 0.368). If you comment out the madvise() for the small-file tests, performance goes down to around 114MB/sec in my test - the cost of taking 2788 VM faults in the cache case. Still better then read(). So what is the final answer? mmap() will be significantly faster for small cached files but the benefits are minimal or even possibly detrimental when used on large uncached files. You also have to consider the effect on the process's VM space. If a program is depending on there being 3G of mmapable space in its address space and you start mmap()ing files for stdio functions, and the program happens to also use a lot of stdio (fopen() and such), you could very well be polluting the mmapable space so much that the program fails. If we were to implement mmap() for stdio, it would have to be done very, very carefully to avoid unwanted side effects. I remember NeXT using mmap() for stdio, and I also remember hitting up against all sorts of weird side effects that caused me to want to tear my hair out. Ultimately I think the best solution is to add a setvbuf() mode #define to set a 'use mmap' mode, e.g. something like _IOMBF, and not have it do it by default. Then programs using the feature could be made portable with a simple #ifdef _IOMBF around the setvbuf call. -Matt /* * readfile [-f/-m] filename * * cc -O2 readfile.c -o rf */ #include #include #include #include #include #include #include #include #include int main(int ac, char **av) { int i; int memMode = -1; int fd; int cksum = 0; const char *path = NULL; struct timeval tv1; struct timeval tv2; struct stat st; struct rusage ru; for (i = 1; i < ac; ++i) { char *ptr = av[i]; if (*ptr != '-') { path = av[i]; continue; } switch(ptr[1]) { case 'f': memMode = 0; break; case 'm': memMode = 1; break; default: fprintf(stderr, "Bad option: %s\n", ptr); exit(1); } } if (memMode < 0) { fprintf(stderr, "Specify mode -f or -m\n"); exit(1); } if (path == NULL) { fprintf(stderr, "Specify file to read\n"); exit(1); } if (stat(path, &st) < 0 || !S_ISREG(st.st_mode)) { fprintf(stderr, "bad filespec: %s\n", path); exit(1); } if ((fd = open(path, O_RDONLY)) < 0) { perror("open"); exit(1); } gettimeofday(&tv1, NULL); if (memMode) { int *base = mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, fd, 0); int n = st.st_size / sizeof(int); int i; if (base == MAP_FAILED) { fprintf(stderr, "unable to mmap file\n"); exit(1); } madvise(base, st.st_size, MADV_WILLNEED); for (i = 0; i < n; ++i) cksum += base[i]; } else { char buf[32768]; int n; while ((n = read(fd, buf, sizeof(buf))) > 0) { n = n / sizeof(int); for (i = 0; i < n; ++i) cksum += buf[i]; } } gettimeofday(&tv2, NULL); getrusage(RUSAGE_SELF, &ru); { double usec = (tv2.tv_usec + 1000000 - tv1.tv_usec) + (tv2.tv_sec - tv1.tv_sec - 1) * 1000000.0; printf("cksum %d read %qd bytes in %4.3f seconds, %4.3f MB/sec cpu %4.3f sec\n", cksum, /* so compiler does not optimize it out */ st.st_size, usec / 1000000.0, (double)st.st_size / (usec * 1024.0 * 1024.0 / 1000000.0), ((ru.ru_utime.tv_usec + ru.ru_stime.tv_usec) + (ru.ru_utime.tv_sec + ru.ru_stime.tv_sec) * 1.0E6) / 1.0E6 ); } return(0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Apr 10 20:13:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id A378D37B423 for ; Tue, 10 Apr 2001 20:13:44 -0700 (PDT) (envelope-from josb@cncdsl.com) Received: (qmail 84111 invoked by uid 1000); 11 Apr 2001 03:13:56 -0000 Date: Tue, 10 Apr 2001 20:13:34 -0700 From: Jos Backus To: freebsd-arch@FreeBSD.ORG Subject: Re: mmap(2) vs read(2)/write(2) Message-ID: <20010410201334.A95042@lizzy.bugworks.com> Reply-To: Jos Backus Mail-Followup-To: freebsd-arch@FreeBSD.ORG References: <20010411095233.P66243@gsmx07.alcatel.com.au> <200104110234.f3B2Ysj97756@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104110234.f3B2Ysj97756@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 10, 2001 at 07:34:32PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Fwiw, /usr/ports/devel/sfio can use mmap() when available, and it supports the stdio API to a large extent. -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Apr 10 20:14:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 782A937B422 for ; Tue, 10 Apr 2001 20:14:40 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3B3FEf82357 for ; Tue, 10 Apr 2001 23:15:14 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 10 Apr 2001 23:15:14 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-arch@FreeBSD.org Subject: Features to facilitate correctness and regression testing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As part of the TrustedBSD work, I'm in the process of developing a small correctness/regression testing suite to (in as much as is possible) exhaustively explore access control implementation correctness. The goal of the suite is to allow me to take a previously identified set of "correct behavior" and verify that, as I introduce changes, correctness is maintained -- something that is very important when introducing new security features. Right now, the suite tests inter-process access control only, but I'm in the process of expanding it to test file system access control. One thing I have noticed in testing inter-process access control is that adding a few helper system calls to the kernel greatly facilitates testing, and allows me to more easily isolate the feature being tested. For example, there are some parts of the process credential (such as the P_SUGID flag) that are modified only implicitly by the userland process. To explore the full interaction space, it is necessary to jump through a large number of hoops that introduce many additional variables into the testing process, whereas I'd like to be able to fashion test suites that test individual features or services (in as much as possible) in isolation. This type of scenario raises a number of questions: 1) To what extent are we interested in including correctness and regression testing suites in the base development tree? It has been suggested to me that these would make a great addition to a new regression/ CVS sub-tree, that they should be included under appropriate existing parts of the tree reflecting what they test, and that they would be best in the form of a port. In any case, I'm very interested in the idea of a "make regression" being easily accessible to developers, to allow them to run fairly intensive correctness tests after making changes. 2) Some helper functions may allow processes to modify system state in such a way as to potentially violate normal limits on system behavior: for example, while not inherently evil, my __setsugid() system call allows a process to turn off the P_SUGID bit if it is currently set. This greatly facilitates setting up test scenarios, but it's not a feature that we necessarily want to introduce in the distributed system. This is area where some discussion is needed: should these features be included in the base system, then be optionally compiled? (options REGRESSION for kernel or NO_REGRESSION=yes in userland) Should these features be independently distributed -- for example, a regression.ko built from src/sys/regression, or even a port? Is the idea of helper functions for regression testing simply philosophically wrong, or does it serve a useful function (I believe the latter, as it allows you to reduce variables and more carefully isolate pieces of behavior for testing, but I'd be interested in the opinions of others). 3) Is it called regression or correctness testing? :-) I've been going by the definition at: http://www.data-dimensions.com/Testers'Network/regression1.htm Also, thanks to Doug Barton for doing some initial discussing of this stuff with me. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Apr 10 23:16:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id F0AC537B424; Tue, 10 Apr 2001 23:16:00 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id QAA29424; Wed, 11 Apr 2001 16:15:57 +1000 (EST) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01K2A2RRBHS0S4NC9O@cim.alcatel.com.au>; Wed, 11 Apr 2001 16:15:46 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f3B6Fra93348; Wed, 11 Apr 2001 16:15:53 +1000 (EST envelope-from jeremyp) Content-return: prohibited Date: Wed, 11 Apr 2001 16:15:53 +1000 From: Peter Jeremy Subject: Re: Features to facilitate correctness and regression testing In-reply-to: ; from rwatson@FreeBSD.ORG on Tue, Apr 10, 2001 at 11:15:14PM -0400 To: Robert Watson Cc: freebsd-arch@FreeBSD.ORG Mail-Followup-To: Robert Watson , freebsd-arch@FreeBSD.ORG Message-id: <20010411161553.U66243@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2001-Apr-10 23:15:14 -0400, Robert Watson wrote: >1) To what extent are we interested in including correctness and > regression testing suites in the base development tree? I'd say it's an excellent idea. Currently our standard test is "make world", but that doesn't do a particularly good job of exercising the overall system. > It has been > suggested to me that these would make a great addition to a new > regression/ CVS sub-tree, that they should be included under > appropriate existing parts of the tree reflecting what they test, > and that they would be best in the form of a port. I'd prefer to see any test code in the tree near the code being tested - this (marginally) improves the chances of tests being updated to cover new functionality. A number of parts of the system already include stand-alone self-checks which could probably be invoked as part of an overall regression test. Pushing the tests into a separate port makes it more difficult for developers to use the tests and would appear to make it harder to update the tests. Any generic test skeleton files probably belong in a "regression" tree under /usr/src. > In any case, I'm > very interested in the idea of a "make regression" being easily > accessible to developers, to allow them to run fairly intensive > correctness tests after making changes. I think there would need to be lots of knobs. Things like the libgmp test suite take a long time to run and are probably overkill for checking that a change in a totally unrelated part of the system works. >2) Some helper functions may allow processes to modify system state in > such a way as to potentially violate normal limits on system behavior: ... > should these > features be included in the base system, then be optionally > compiled? Since you are talking about changing the security-related behaviour of the system, I'd prefer it to require an "options REGRESSION" (and maybe then set a sysctl), rather than be a KLD. I'm not at all keen on the idea of having it stashed away as a separately maintained port. > Is the idea of helper functions for regression testing simply > philosophically wrong, or does it serve a useful function I think it's a valid part of white-box testing. In any piece of software, there are going to be code paths that are very difficult or impossible to exercise using the `normal' interfaces. Providing interfaces that are intended solely for testing the correctness of the code seems perfectly reasonable. This is no different to the JTAG ports on virtually every modern LSI chip. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Apr 10 23:54:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 5FE7F37B422 for ; Tue, 10 Apr 2001 23:54:28 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3B6rCT98951; Tue, 10 Apr 2001 23:53:12 -0700 (PDT) (envelope-from dillon) Date: Tue, 10 Apr 2001 23:53:12 -0700 (PDT) From: Matt Dillon Message-Id: <200104110653.f3B6rCT98951@earth.backplane.com> To: Andrew Heybey Cc: Peter Jeremy , freebsd-arch@FreeBSD.ORG Subject: Re: mmap(2) vs read(2)/write(2) References: <20010411095233.P66243@gsmx07.alcatel.com.au> <200104110234.f3B2Ysj97756@earth.backplane.com> <85d7akqf9h.fsf@stiegl.niksun.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I discovered this a while ago myself. In my experiment I did :madadvise(..., MADV_SEQUENTIAL) rather than MADV_WILLNEED. Would :doing MADV_SEQUENTIAL in addition to MADV_WILLNEED be useful? As of 4.1 the VM heuristic does a really excellent job figuring out your access pattern, so you do not need to lock it in with an madvise(). Also as of 4.1 or so the VM fault patterns are tracked on a per-process basis (in the vm_map_entry), independant of accesses made by other processes and also independant of VFS operations like lseek(), read(), and write(). And, since it's done in the vm_map_entry, the fault patterns are regionalized within each mmap'd block. So the VM system's heuristic will not get confused if several processes are accessing the same file in different ways and can also calculate the heuristic on the different mmap'd areas (data, bss, text, shared libraries, multiple mmap()'s that you make) independantly. So MADV_WILLNEED (and perhaps DONTNEED) is really all you need to be optimal. :Another thing that I noticed is that if the data are not already in :the cache, then mmap() will read from disk every time (even if the :file will fit in memory) while read() will leave the data in the :cache. So when reading a file that will fit in memory, the fastest was :read the first time followed by mmap for subsequent passes. This was :on 3.2, however, maybe things have changed since then? : :andrew 4.x definitely caches the data read in through page faults. 3.x should have too, though perhaps not quite as well. We've done a bunch of work in 4.x to try to prevent cache blow-aways, which may be what you are seeing. A cache blow-away is where you have a normal system with a bunch of cached data and then go in and blow it away by, say, greping through a 1G file . Obviously for that case you do not want the scan of the 1G file to blow away all the wonderfully cached data you already have! Just accessing a piece of data once is not enough to cache it over data that might already be in the cache. Example: ./rf -m test2 ./rf -m test2 ./rf -m test2 cksum 0 read 33554432 bytes in 0.270 seconds, 118.310 MB/sec cpu 0.273 sec ns1:/home/dillon> ./rf -f test1 cksum 0 read 1073741824 bytes in 43.381 seconds, 23.605 MB/sec cpu 11.228 sec ns1:/home/dillon> ./rf -m test2 cksum 0 read 33554432 bytes in 0.271 seconds, 118.288 MB/sec cpu 0.265 sec Remember, test1 is the huge file, test2 is the small file. We force test2 into the cache more permanently by repeatedly accessing it. We then sequentially read test1. But note that when we read test2 again that it still gets 118MB/sec ... the read of the 1G test1 file did *NOT* blow away the system's cache of the test2 data. Here's another example. If you blow away the cache by reading test1 through an mmap, then try to read test2 through an mmap a couple of times: ns1:/home/dillon> ./rf -m test1 cksum 0 read 1073741824 bytes in 48.717 seconds, 21.019 MB/sec cpu 11.962 sec ns1:/home/dillon> ./rf -m test2 cksum 0 read 33554432 bytes in 0.945 seconds, 33.873 MB/sec cpu 0.329 sec ns1:/home/dillon> ./rf -m test2 cksum 0 read 33554432 bytes in 0.898 seconds, 35.636 MB/sec cpu 0.290 sec ns1:/home/dillon> ./rf -m test2 cksum 0 read 33554432 bytes in 0.418 seconds, 76.566 MB/sec cpu 0.272 sec ns1:/home/dillon> ./rf -m test2 cksum 0 read 33554432 bytes in 0.271 seconds, 118.153 MB/sec cpu 0.272 sec ns1:/home/dillon> ./rf -m test2 cksum 0 read 33554432 bytes in 0.271 seconds, 118.243 MB/sec cpu 0.272 sec Notice that test2 is not being 100% cached in the first pass. test2 in this case is 32MB of data. The system is not willing to throw away 32MB of data cached prior to accessing test2. But after a couple of scans of test2 the system figures out that you really do want to cache all 32MB. Now, unfortunately, the blow-away prevention algorithm has not yet been refined, so it has different effects on read() verses mmap/read methods of scanning a file. It works for both, but read() goes through the buffer cache and since backing pages for the buffer cache are wired, read() winds up with a small edge over mmap() in regards to page priority. Blow-away is handled through a combination of several algorithms. First the VM PAGE queue's native priority assignment algorithm gives newly cached pages a 'neutral' priority rather then a high priority, which gives them room to go up or down in priority (Rik is very familiar with this). This is the bullwork. There are two other algorithms involved, however. First, the sequential heuristic attempts to depress the priority of pages behind the read at the same time it attempts to read pages ahead of the read. Second, the VM system has a little algorithm to avoid silly-recycling syndrome. This occurs when all the pages in the system are at a higher priority and you wind up instantly (too quickly) recycling the pages you just read in due to their neutral priority. The solution is to not blindly depress the priority of pages behind the read but to instead give a small percentage of them a higher priority so they stick around longer. If you were to repeat the above test using ./rf -f test2 you would notice that it caches the whole file right off the bat, whereas ./rf -m test2 did not cache the whole (32MB) file right off the bat. This is an example of the differences that still exist between VFS ops and MMAP ops. It's good enough to prevent cache blow-aways, but isn't yet optimal or generic across the different access methods. Ya never thought caching could be this complicated, eh? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 11 0:12:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A668F37B424 for ; Wed, 11 Apr 2001 00:12:30 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3B7Cwf85038; Wed, 11 Apr 2001 03:12:59 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 11 Apr 2001 03:12:57 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Peter Jeremy Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Features to facilitate correctness and regression testing In-Reply-To: <20010411161553.U66243@gsmx07.alcatel.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 11 Apr 2001, Peter Jeremy wrote: > > It has been > > suggested to me that these would make a great addition to a new > > regression/ CVS sub-tree, that they should be included under > > appropriate existing parts of the tree reflecting what they test, > > and that they would be best in the form of a port. > > I'd prefer to see any test code in the tree near the code being tested > - this (marginally) improves the chances of tests being updated to > cover new functionality. A number of parts of the system already > include stand-alone self-checks which could probably be invoked as > part of an overall regression test. Pushing the tests into a > separate port makes it more difficult for developers to use the > tests and would appear to make it harder to update the tests. > > Any generic test skeleton files probably belong in a "regression" > tree under /usr/src. Where do you think that kernel regression tests should be placed? Often, these tests will be initiated and managed from userland, so they are probably inappropriate to drop in sys/? > Since you are talking about changing the security-related behaviour of > the system, I'd prefer it to require an "options REGRESSION" (and maybe > then set a sysctl), rather than be a KLD. I'm not at all keen on the > idea of having it stashed away as a separately maintained port. One of my primary motivations for looking at importing the features into the base kernel was to avoid both the non-use, bitrot and synchronization problems currently inherent to ports. Ports with kld's suffer breakage in a number of ways, due to lack of synchronization with the base tree, difficulty in maintaining up-to-date kld builds when the system is a moving target, etc. (For example, I rebuild my workstation almost daily on -CURRENT -- and I have to rebuild my vmware kld's about as frequently or risk panics). For many consumers sitting on a release, this may be less of a problem, but for a development tool on the -CURRENT branch, it's a serious problem. Does this mean we need a which provides constants and prototypes for regression-specific interfaces which are enabled using options REGRESSION? (This is how I have it implemented in my local source tree, but I'm interested in whether this seems like a good idea to anyone else :-). > > Is the idea of helper functions for regression testing simply > > philosophically wrong, or does it serve a useful function > > I think it's a valid part of white-box testing. In any piece of > software, there are going to be code paths that are very difficult or > impossible to exercise using the `normal' interfaces. Providing > interfaces that are intended solely for testing the correctness of the > code seems perfectly reasonable. This is no different to the JTAG ports > on virtually every modern LSI chip. Sounds good to me -- I think we agree on almost all points. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 11 0:56:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id BB99737B423 for ; Wed, 11 Apr 2001 00:56:48 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id JAA94450; Wed, 11 Apr 2001 09:56:40 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Alfred Perlstein Cc: Peter Jeremy , freebsd-arch@FreeBSD.ORG Subject: Re: mmap(2) vs read(2)/write(2) References: <20010411095233.P66243@gsmx07.alcatel.com.au> <20010410171522.H15938@fw.wintelcom.net> From: Dag-Erling Smorgrav Date: 11 Apr 2001 09:56:40 +0200 In-Reply-To: <20010410171522.H15938@fw.wintelcom.net> Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein writes: > Peter, the stdio would still have to copy the data into the user > supplied buffer Not for fgetln()... DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 11 1: 2:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 27EF137B424 for ; Wed, 11 Apr 2001 01:02:42 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3B82Zd23913; Wed, 11 Apr 2001 01:02:35 -0700 (PDT) Date: Wed, 11 Apr 2001 01:02:35 -0700 From: Alfred Perlstein To: Dag-Erling Smorgrav Cc: Peter Jeremy , freebsd-arch@FreeBSD.ORG Subject: Re: mmap(2) vs read(2)/write(2) Message-ID: <20010411010235.N15938@fw.wintelcom.net> References: <20010411095233.P66243@gsmx07.alcatel.com.au> <20010410171522.H15938@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Wed, Apr 11, 2001 at 09:56:40AM +0200 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Dag-Erling Smorgrav [010411 00:56] wrote: > Alfred Perlstein writes: > > Peter, the stdio would still have to copy the data into the user > > supplied buffer > > Not for fgetln()... Well not only that, the mmap'ing could avoid the initial copy invoved in buffering. Basically, it does avoid the copy, but the vm overhead is something to investigate, it shouldn't just be implemented on a whim. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 11 2:43:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 764A737B422; Wed, 11 Apr 2001 02:43:36 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (8rl4kw@localhost [127.0.0.1]) by green.dyndns.org (8.11.2/8.11.1) with ESMTP id f3B9gJa17869; Wed, 11 Apr 2001 05:42:19 -0400 (EDT) (envelope-from green@FreeBSD.org) Message-Id: <200104110942.f3B9gJa17869@green.dyndns.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Robert Watson Cc: Peter Jeremy , freebsd-arch@FreeBSD.org Subject: Re: Features to facilitate correctness and regression testing In-Reply-To: Your message of "Wed, 11 Apr 2001 03:12:57 EDT." From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Apr 2001 05:42:18 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson wrote: > On Wed, 11 Apr 2001, Peter Jeremy wrote: > > > > It has been > > > suggested to me that these would make a great addition to a new > > > regression/ CVS sub-tree, that they should be included under > > > appropriate existing parts of the tree reflecting what they test, > > > and that they would be best in the form of a port. > > > > I'd prefer to see any test code in the tree near the code being tested > > - this (marginally) improves the chances of tests being updated to > > cover new functionality. A number of parts of the system already > > include stand-alone self-checks which could probably be invoked as > > part of an overall regression test. Pushing the tests into a > > separate port makes it more difficult for developers to use the > > tests and would appear to make it harder to update the tests. > > > > Any generic test skeleton files probably belong in a "regression" > > tree under /usr/src. > > Where do you think that kernel regression tests should be placed? Often, > these tests will be initiated and managed from userland, so they are > probably inappropriate to drop in sys/? You mean like, oh, say src/tools/regression? ^_^ There are odd-men-out, of course; several of the src/bin and src/usr.bin apps inherited regression tests also (e.g. ed and sed). I think those should probably be fixed by leaving the tests where they are and sticking a Makefile to run those tests in src/tools/regression. There are also the libc_r ones -- those can be very useful -- which should probably be repo-copied to the regression test tree proper. In any case, I think it's a very good idea! I'm reasonably certain we discussed regression tests in the tree 1-2 years ago, however it may not have been on the mailing lists, and only on IRC logs. If just IRC, DES or I can probably remember any prevailing ideas from back then if we try. As far as enabling the non-intrusive regression instrumentation by default, I think in -CURRENT it should be, so there should be two options which both enable regression test instrumentation and which enable intrusive instrumentation. In this particular case, I don't think there's anything to lose by enabling that syscall by default as a "non-intrusive" frob. You could always just write support for that operation into procfs(4) ;) -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 11 13:24:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 85C5437B422; Wed, 11 Apr 2001 13:24:43 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3BKPHf93955; Wed, 11 Apr 2001 16:25:17 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 11 Apr 2001 16:25:17 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Brian F. Feldman" Cc: Peter Jeremy , freebsd-arch@FreeBSD.org Subject: Re: Features to facilitate correctness and regression testing In-Reply-To: <200104110942.f3B9gJa17869@green.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 11 Apr 2001, Brian F. Feldman wrote: > As far as enabling the non-intrusive regression instrumentation by > default, I think in -CURRENT it should be, so there should be two > options which both enable regression test instrumentation and which > enable intrusive instrumentation. In this particular case, I don't > think there's anything to lose by enabling that syscall by default as a > "non-intrusive" frob. You could always just write support for that > operation into procfs(4) ;) For "options REGRESSION" compile-time enabled system calls, is it worth introducing a , or should they just be stuffed into other related include files? Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 11 14:42: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by hub.freebsd.org (Postfix) with SMTP id DECBF37B422 for ; Wed, 11 Apr 2001 14:42:00 -0700 (PDT) (envelope-from jkf@aura.research.bell-labs.com) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Wed Apr 11 17:40:08 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Wed Apr 11 17:40:10 EDT 2001 Received: (from jkf@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id RAA14852; Wed, 11 Apr 2001 17:40:07 -0400 (EDT) Date: Wed, 11 Apr 2001 17:40:07 -0400 (EDT) From: Jeff Fellin Message-Id: <200104112140.RAA14852@aura.research.bell-labs.com> To: freebsd-arch@FreeBSD.org, freebsd-smp@FreeBSD.org Subject: Making a driver SMP-safe Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm not sure this belongs here or in bsd-smp, so I'm dual posting it. I have a question on what the actual interfaces, and if there are any guidelines on how to convert a device driver that runs in a UniProcessor environement to one that can run on concurrent CPU's in a MultiProcessor environment. Many of the archives talk about mutexes in general, but I haven't seen a concise description of how a driver needs to deal with SMP issues. I have written several SMP drivers using the POSIX and other SMP mutex schemes, so I need to know the API's. I have built my driver on an SMP kernel (STABLE) and it works, at least to funky lock panics. So, I assume something was done to prevent concurrent access to my driver in STABLE. I would like to know what was done to protect the driver from executing concurrently. Any pointers to documents or mail archive entries I may have missed in my searches is appreciated. Jeff Fellin Bell Labs, Murray Hill NJ (908) 582-7673 fellin@lucent.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 11 15: 5:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id F34BB37B422; Wed, 11 Apr 2001 15:05:31 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3BM5GG10418; Wed, 11 Apr 2001 15:05:16 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200104112140.RAA14852@aura.research.bell-labs.com> Date: Wed, 11 Apr 2001 15:04:46 -0700 (PDT) From: John Baldwin To: Jeff Fellin Subject: RE: Making a driver SMP-safe Cc: freebsd-smp@FreeBSD.org, freebsd-arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 11-Apr-01 Jeff Fellin wrote: > > I'm not sure this belongs here or in bsd-smp, so I'm dual posting it. > > I have a question on what the actual interfaces, and if there are > any guidelines on how to convert a device driver that runs in a > UniProcessor environement to one that can run on concurrent CPU's > in a MultiProcessor environment. > > Many of the archives talk about mutexes in general, but I haven't > seen a concise description of how a driver needs to deal with SMP > issues. I have written several SMP drivers using the POSIX and other > SMP mutex schemes, so I need to know the API's. > > > I have built my driver on an SMP kernel (STABLE) and it works, > at least to funky lock panics. So, I assume something was done to > prevent concurrent access to my driver in STABLE. I would like to > know what was done to protect the driver from executing concurrently. In stable there is a giant spin lock around the entire kernel, which protects your driver. In -current it's a bit different, but at this point in time it all looks the same to the drivers as there is a Giant mutex that protects 99% of the kernel still. Later on when Giant is split up driver's will start needing to use locks to protect their data as well as to access shared data. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 11 15:13:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E2F9237B423; Wed, 11 Apr 2001 15:13:24 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA04999; Wed, 11 Apr 2001 15:13:27 -0700 Date: Wed, 11 Apr 2001 15:13:19 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jeff Fellin Cc: freebsd-smp@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: RE: Making a driver SMP-safe In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jeff- from what I know of your project, you'll have to wait until CAM is SMP-ized anyway. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 11 21: 3: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 99C9437B496 for ; Wed, 11 Apr 2001 21:02:57 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3C43Uf98927 for ; Thu, 12 Apr 2001 00:03:31 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 12 Apr 2001 00:03:30 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-arch@FreeBSD.org Subject: Combining pcred and ucred Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Right now, two structures are used to define the process credential set. First, there is the ucred structure, which maintains what most developers think of when asked about a credential structure: the effective uid, effective gid, and additional groups. More recently, ucred has grown to include a cached uidinfo reference, and the prison pointer associated with the jail() code. There is also a pcred structure, which includes a reference to the process's ucred, as well as additional process credentials, such as the real uid and gid, saved uid and gid, and an additional uidinfo pointer. The reference semantics are effectively as follows: there is exactly one pcred structure per process (although the pcred structure does contain a reference count field, I don't know of situations where it is used--it seems only to get set to 1, or be decremented, never incremented). Each pcred points to a ucred, but that ucred may be shared (in effect, copy-on-write). When a process performs an activity requiring a persistent cached credential, such as a file or socket open, or in the future, a potentially blocking VFS operation, an additional reference is added. When the ucred needs to be modified, a copy-on-write is performed using crcopy(), allowing the process's ucred to diverge from the cached ucred's. The observation may be made that although one possible rationale for the division of ucred and pcred is that pcred might get modified while ucred remains constant, reducing the number of copy-on-writes, in fact ucred is almost always (if not always) modified when the pcred needs to be modified. There is a small space savings associated with not caching the real and saved uid/gid's all over the place, but this is negligible due to the power-of-two memory allocation model, overhead of maintaining additional refcounts, pointers, and uidinfo references, and the copy-on-write nature of ucred. In fact, the pcred pointer substantially complicates proc locking, and increases the cost of credential evaluation and manipulation by introducing additional structures and dreferences. I think there is a reasonable argument to be made that pcred should be merged back into ucred, making ucred the sole source of credential information for the process. In fact, I'd like to propose doing this, as it allows the more extensive use of direct ucred to ucred comparison in access control, rather than proces to process (hence the proc locking issue). There is one additional piece of information, that I know of, that should probably move into ucred if pcred moves into ucred: this is the P_SUGID flag, which is currently in the process flag field, bit might be more formally considered a credential downgrade or credential modification flag. Moving this flag into ucred would allow the flag to be available for access control operations based on the ucred, which would also have substantial structural benefits, albeit at the slight increase in cost associated with ucred caching. I would welcome thoughts on these issues: I don't currently have patches, although Thomas Moestl, John Baldwin, and I have discussed subsets of the overall issue a number of times in the past. Moving pcred into ucred would simplify a number of pieces of code, and not be a challenging change to implement. The seperation of ucred and xucred means that this will not introduce binary incompatibility in userland. In fact, arguably xucred should undergo similar modifications as consumers of xucred may wish to evaluate the real/saved credentials also. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 11 21:39:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A959137B59E; Wed, 11 Apr 2001 21:39:08 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3C4cdf99274; Thu, 12 Apr 2001 00:38:39 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 12 Apr 2001 00:38:39 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: jon@licq.org Cc: tmm@FreeBSD.org, Eivind Eklund , arch@FreeBSD.org Subject: Re: suser security In-Reply-To: <20010327132808.B14068@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Mar 2001, Eivind Eklund wrote: > > Last year I was working on changing the uid compares to 0 to suser() calls. > > I lost direct internet access for a period of time so was unable to keep > > current with the tree. Anyways, I have time and resources to work on it > > again and saw that it was still on the list of things to do. I also found > > my notes on what files needed patched, the other day when I was cleaning my > > room up. > > > > So just let me know if it's still needed. Perhaps you can tell me what you > > would like suser() to do? I remember you mentioned a logging facility I > > believe. I could work on that part as well, since obviously the changing to > > suser isn't much of a challenge. > > The point was that suser() takes a process argument, and logs which > processes have used superuser capabilities (ie, have needed the call to > suser()). This was relevant at the point the entry was added to the > TODO list, but I'm not sure it is relevant now. > > Robert Watson (Cc'ed) is working on adding ACLs > and process capabilities to FreeBSD. This work touches the same areas, > and I am not quite sure how it will interact. I think it might be > better to coordinate this with him. Jon, Sorry for the delay in getting back to you -- things are, as always, pretty busy around here and I've been slipping up on my e-mail. Eivind is correct in pointing out that a number of pieces of work are on-going which affect the suser/privilege-related code, including the implementation of POSIX.1e Capabilities as part of the TrustedBSD Project. Currently Thomas Moestl is working on that implementation, so I've CC'd this message to him also. I've also CC'd the trustedbsd-discuss mailing list, since there's a fair amount of architectural commentary here that others might be interested in commenting on. Here are a few comments on the ideas expressed in your and Eivind's messages: 1) There remain a number of places in the kernel where the credential or process effective uid is directly compared with 0, rather than making use of the suser() or suser_xxx() primitives. The reason for this is interesting, and actually related to one of your other points. Originally, suser() set the ASU process accounting flag when it was invoked, in an attempt to account for use of superuser privilege. However, the goal was that this flag only be set when privilege was actually employed, not when it was tested, so rather than use suser() in situations where it was tested but not necessarily employed, manual tests were performed. Consider, for example, some of the compound security checks performed in the UFS code: privilege can be used to override some but not all of the checks (such as system file flags under securelevel>0). Rather than call suser early in the check and set ASU incorrectly, the caller would manually test. Clearly, this is a problem, as it means that the security primitives are not used, resulting in inconsistent implementations throughout the kernel. In the capability implementation, instances of suser() and suser_xxx() are being replaced with the cap_check() call, which checks the passed process or credential for specific POSIX.1e privileges; as such, it is now necessary to replace the remaining direct uid checks with calls to cap_check(), as suser() will no longer be used in most situations. In my first implementation of the Capability code, I broke out the setting of the ASU bit from the suser() call and placed it in a seperate primitive, suser_used(p); this allowed calls to be made to suser() without incorrectly setting the ASU bit. In doing this, I discovered that the ASU bit was frequently misused throughout the tree already, especially in the network code where often a single invocation of suser() is made, and then the result cached for later use deeper in the stack. On realizing this, I proposed an alternative strategy: for the time being, we would disable the ASU functionality, since it is infrequently (if at all) used, and was incorrect in many situations anyway. In the second capability implementation, currently being worked on by Thomas, it is assumed that ASU no longe needs to be maintained, substantially simplifying the code (if you look in 5.0-CURRENT, you'll note that various authorization calls are careful to return a "privileged used" result via an optional call-by-reference privused pointer so that the caller can then use suser_used(), which in turn introduces complexity). I suspect that Thomas has caught most of the remaining uid calls, but once he publishes the next version of the capability patch, we'd welcome your work on it to catch remaining instances, and to comment on correctness. 2) The second point that is raised in your and Eivind's e-mails is that of introducing additional logging behavior in suser(). As I've mentioned above, there are a number of substantial technical and philosophical reasons why this might be a bad idea, especially relating to seperating the checking of privilege and the actual use of privilege to perform an operation during a compound access control check. However, the fact that this particular approach may not be the best one doesn't mean that the service is not leaded: one of the (thus far under-visited) goals of the TrustedBSD project is to provide some form of fine-grained event auditing; this audit log would be more useful if it did allow the auditing of the use of privilege (without capabilities, simply the necessary invocation of superuser privileges, but with privileges, also an indication of which privileges were required, if any, for the operation to succeed). Andrew Reiter has been preparing an auditing subsystem requirements document, as well as descriptions of implementations on other platforms so that we can go through a more informed design process. Having partially implemented auditing on FreeBSD twice in the past, I can comment both on the complexity of correct implemetation, and the need to be sensitive to issues of simplicity, maintainability, and performance. Taking a fairly deep look into other implementations will be important to developing an audit implementation that can be accepted by the FreeBSD community. This is certainly an area where both your contributions in the form of ideas and implementation would be most welcome. In any case, I'd greatly welcome your participation in improving the security and correctness of FreeBSD, and invite you to join the TrustedBSD mailing lists since TrustedBSD seems to be the current source of many of the types of changes you're considering implementing. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 12 15:51: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by hub.freebsd.org (Postfix) with ESMTP id BBD8B37B496 for ; Thu, 12 Apr 2001 15:51:04 -0700 (PDT) (envelope-from dmlb@dmlb.org) Received: from dmlb.org ([62.253.135.104]) by mta02-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20010412225103.DYKC290.mta02-svc.ntlworld.com@dmlb.org> for ; Thu, 12 Apr 2001 23:51:03 +0100 Received: from dmlb by dmlb.org with local (Exim 3.03 #1) id 14npvb-000Fsz-00 for freebsd-arch@freebsd.org; Thu, 12 Apr 2001 23:51:03 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 12 Apr 2001 23:51:02 +0100 (BST) From: Duncan Barclay To: freebsd-arch@freebsd.org Subject: Use of if_ef for 802.11 interfaces? Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Currently, I'm updating if_ray to work with newer cards and access points. In doing this I have to have code to cope with hacking the ethernet header around. For example on transmit I need: o build 802.11 header (add source, destination and BSS or AP address and a few flags) o then encapsulate, or (802.11 header pre-pended to complete Ethernet II packet) o translate (remove Ethernet header, replace with 802.11 header and RFC1042 LLC/SNAP) Most (awi, if_wi) other 802.11 drivers need to do something similar. In digging around I re-discovered if_ef and wondered if this is a good place to add this functionality? A couple of practical points arise for outgoing packets revolving around the type of 802.11 network in use (infrastructure or adhoc) that would involve if_ef knowing what mode the interface is in and the BSSID. We have some common support for this in the form of the recent (uncommitted) patches to ifconfig PR25577. In summary, o is if_ef the best place for this? o if not, would an 80211_input() be useful? o if not, I'll copy the code from awi.c Duncan PS. I have also noticed that most of the 802.11 drivers that divine whether RFC1042 is being used on received packets can potentially get things a bit wrong by incompletely parsing the .11 header. This can be trivially fixed though. --- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@dmlb.org | the alcoholics, and the permanently stoned. dmlb@freebsd.org| Steven King To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Apr 13 2:59:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 43CDA37B43E for ; Fri, 13 Apr 2001 02:59:20 -0700 (PDT) (envelope-from oppermann@monzoon.net) Received: (qmail 60632 invoked from network); 13 Apr 2001 09:59:17 -0000 Received: from unknown (HELO monzoon.net) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 13 Apr 2001 09:59:17 -0000 Message-ID: <3AD6CD6E.104C6DD9@monzoon.net> Date: Fri, 13 Apr 2001 11:57:02 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Duncan Barclay Cc: freebsd-arch@freebsd.org Subject: Re: Use of if_ef for 802.11 interfaces? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Duncan Barclay wrote: > > Hi > > Currently, I'm updating if_ray to work with newer cards and access points. In > doing this I have to have code to cope with hacking the ethernet header > around. For example on transmit I need: > > o build 802.11 header > (add source, destination and BSS or AP address and a few > flags) > > o then encapsulate, or > (802.11 header pre-pended to complete Ethernet II packet) > > o translate > (remove Ethernet header, replace with 802.11 header and > RFC1042 LLC/SNAP) > > Most (awi, if_wi) other 802.11 drivers need to do something similar. In > digging around I re-discovered if_ef and wondered if this is a good > place to add this functionality? At the wi() and an() don't have the need for that as they have a mode that does this encapsulation of RFC1042 frames to IEEE802.11 in the card's firmware. For example in the wi() driver it is not possible (with just public documentation) to send 802.11 frames yourself. Otherwise I'd say make 802.11 a real layer2 infrastructure with it's own input routines (a la ethernet/tokenring). > A couple of practical points arise for outgoing packets revolving > around the type of 802.11 network in use (infrastructure or adhoc) > that would involve if_ef knowing what mode the interface is in and the > BSSID. We have some common support for this in the form of the recent > (uncommitted) patches to ifconfig PR25577. Wireless support in ifconfig would be really a good thing IMHO. But this brings the need of a well thought out interface between ifconfig and the wireless card drivers. > In summary, > o is if_ef the best place for this? Not IMO. > o if not, would an 80211_input() be useful? In principal yes but just for one driver? > o if not, I'll copy the code from awi.c > > Duncan > > PS. > > I have also noticed that most of the 802.11 drivers that divine whether > RFC1042 is being used on received packets can potentially get things a > bit wrong by incompletely parsing the .11 header. This can be trivially > fixed though. PS: My bread an butter for the next years is wireless stuff so (see www.monzoon.net, everthing is freebsd based, even the access points at the moment I'm digging myself in there and working on a proposal of how integrate the wireless stuff in the best into the base system (ifconfig et al.). The current structure was ok for now but in the future with increased wireless usage it won't hold. It should be possible to set the wireless mode by typing 'ifconfig wi0 ibss 1234' just like selecting an ether media type. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Apr 13 3:13:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 9BDB937B424 for ; Fri, 13 Apr 2001 03:13:39 -0700 (PDT) (envelope-from julian@elischer.org) Received: (qmail 16141 invoked by uid 666); 13 Apr 2001 10:16:11 -0000 Received: from i188-164.nv.iinet.net.au (HELO elischer.org) (203.59.188.164) by mail.m.iinet.net.au with SMTP; 13 Apr 2001 10:16:11 -0000 Message-ID: <3AD6D134.180707A3@elischer.org> Date: Fri, 13 Apr 2001 03:13:08 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Duncan Barclay Cc: freebsd-arch@freebsd.org Subject: Re: Use of if_ef for 802.11 interfaces? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Duncan Barclay wrote: > > Hi > > Currently, I'm updating if_ray to work with newer cards and access points. In > doing this I have to have code to cope with hacking the ethernet header > around. For example on transmit I need: > > o build 802.11 header > (add source, destination and BSS or AP address and a few > flags) > > o then encapsulate, or > (802.11 header pre-pended to complete Ethernet II packet) > > o translate > (remove Ethernet header, replace with 802.11 header and > RFC1042 LLC/SNAP) > > Most (awi, if_wi) other 802.11 drivers need to do something similar. In > digging around I re-discovered if_ef and wondered if this is a good > place to add this functionality? I am looking at building a set of Netgraph nodes for mangling 802.11 packets. I will possibly be doing WEP and AP related functions on netgraph nodes. What code do you already have? I see Andre has already spoken up. We would be working on this. > > A couple of practical points arise for outgoing packets revolving > around the type of 802.11 network in use (infrastructure or adhoc) > that would involve if_ef knowing what mode the interface is in and the > BSSID. We have some common support for this in the form of the recent > (uncommitted) patches to ifconfig PR25577. > > In summary, > o is if_ef the best place for this? > o if not, would an 80211_input() be useful? > o if not, I'll copy the code from awi.c > > Duncan > > PS. > > I have also noticed that most of the 802.11 drivers that divine whether > RFC1042 is being used on received packets can potentially get things a > bit wrong by incompletely parsing the .11 header. This can be trivially > fixed though. > > --- > ________________________________________________________________________ > Duncan Barclay | God smiles upon the little children, > dmlb@dmlb.org | the alcoholics, and the permanently stoned. > dmlb@freebsd.org| Steven King > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Apr 13 10:24:56 2001 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 C1A7337B43E for ; Fri, 13 Apr 2001 10:24:53 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f3DHOik19616; Fri, 13 Apr 2001 10:24:44 -0700 Date: Fri, 13 Apr 2001 10:24:44 -0700 From: Brooks Davis To: Andre Oppermann Cc: Duncan Barclay , freebsd-arch@FreeBSD.ORG Subject: Re: Use of if_ef for 802.11 interfaces? Message-ID: <20010413102444.C664@Odin.AC.HMC.Edu> References: <3AD6CD6E.104C6DD9@monzoon.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="DSayHWYpDlRfCAAQ" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AD6CD6E.104C6DD9@monzoon.net>; from oppermann@monzoon.net on Fri, Apr 13, 2001 at 11:57:02AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 13, 2001 at 11:57:02AM +0200, Andre Oppermann wrote: > > A couple of practical points arise for outgoing packets revolving > > around the type of 802.11 network in use (infrastructure or adhoc) > > that would involve if_ef knowing what mode the interface is in and the > > BSSID. We have some common support for this in the form of the recent > > (uncommitted) patches to ifconfig PR25577. >=20 > Wireless support in ifconfig would be really a good thing IMHO. But > this brings the need of a well thought out interface between ifconfig > and the wireless card drivers. What, if anything, is wrong with the interface proposed in PR 25577? -- 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 --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE61zZbXY6L6fI4GtQRApY+AKC/7io9mIn5pnKpO7/uRcqfbY66ywCfWIs7 pgkZ6fSF73M5RYX4Qm/EAxw= =R5W5 -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message