From owner-freebsd-arch Sun Oct 24 0: 6:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 742AB1505F for ; Sun, 24 Oct 1999 00:06:47 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id JAA06533 for ; Sun, 24 Oct 1999 09:06:46 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA09434 for freebsd-arch@freebsd.org; Sun, 24 Oct 1999 09:06:46 +0200 (MET DST) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 23B561508F for ; Sun, 24 Oct 1999 00:06:38 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11fHjg-0004HC-00; Sun, 24 Oct 1999 01:06:37 -0600 Message-ID: <3812AFFB.B028C64D@softweyr.com> Date: Sun, 24 Oct 1999 01:06:35 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: arch@freebsd.org Subject: Re: Racing interrupts References: <199910240608.AAA34462@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > Consider the following situation. There is a driver talking to a > device. An unmasked interrupt happens and the device is now gone. > How does the driver know to stop what it is doing and respond to this > disappearance in a sane way? > > This sort of situation comes up in the pccard code. When someone > ejects the card, an interrupt fires. If I were to remove the device > from the tree in the interrupt handler, I can invalidate the softc > that the driver is still using by freeing it. At that point the > driver is running out of freed memory and all bets are off. > > I can schedule a timeout to happen in 0 clock ticks so that it is then > "safe" to remove the device, but the hardware is either gone or very > close to being gone when the first interrupt happens, so we've moved > the problem from memory corruption to a hardware hang. > > It would be nice if there was some way to ref/unref the use of softc > so I could remove the device right away, but defer the actual removal > of the device and softc until the last deref of softc. This strikes > me as a major PITA and may still result in a hardware hang. > > It is my understanding that the pccard hardware still still exist for > a period of time after the card is ejected (since it takes some period > of time to move from the pins that caused the interrupt to the > power/control/data pins being disabled). I don't know if this is > true, or if true what the period of time is. > > What I really want is a kernel signal mechanism which will start a > rundown of the driver thread which is not allowed to touch hardware, > but can only free resources used by the driver. We have lots of tight > loops in drivers in the kernel and it seems unwise to pessimize those > so that this race can be dealt with... > > Comments? This has recently been dealt with by the Linux group at Motorola, adding support for Compact PCI. I don't know if it's been incorporated into the Linux kernel yet, but I can find out. If not, I'm pretty certain I can get you a look at the code if it will be helpful at all. -- "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 Sun Oct 24 20:27: 3 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 339A6151BD for ; Sun, 24 Oct 1999 20:26:42 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA19820 for ; Mon, 25 Oct 1999 05:26:38 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA12383 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 05:26:37 +0200 (MET DST) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 3FCD714A24 for ; Sun, 24 Oct 1999 20:26:18 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id UAA29980; Sun, 24 Oct 1999 20:26:15 -0700 Date: Sun, 24 Oct 1999 20:26:13 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910240608.AAA34462@harmony.village.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 > What I really want is a kernel signal mechanism which will start a > rundown of the driver thread which is not allowed to touch hardware, > but can only free resources used by the driver. We have lots of tight > loops in drivers in the kernel and it seems unwise to pessimize those > so that this race can be dealt with... Presumably the interrupt that notifies one that a card has been pulled is actually then managed by the bus device driver for that bus. This should ensure that the the bus nexus controlller is notified that the state of the hardware is changed. This does nothing for threads that were active at the time of the interrupt. In this case, either the hardware is sane enough to continue to provide some rational non-faulting access (in the case of memory mapping), or you have to design a framework such that when the interrupt occurs, and the nexus driver now knows how to remap any memory mappings so that a safe non-faulting (if nonsensical) access can occur. Then some additional mechanism which notifies the actual node driver that things have changed will be invoked. For systems I'm more familiar with, explicit obligate parent-child relationships have these specific notification mechanisms specified on a per parent-child type basis. It's hard to generalize such mechanisms into a usable general event notification mechanism because each bus has different possible async events. A PC cardbus has removal/insertion, a fibre channel arbitrated loop has LIP and then (re)arbitration for AL_PAs- who knows what Compact PCI provides? What does newbus provide for this? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 9:47:14 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5C7AD14D90 for ; Mon, 25 Oct 1999 09:47:11 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA05416 for ; Mon, 25 Oct 1999 18:47:07 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA15365 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 18:47:06 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 008CA14D90 for ; Mon, 25 Oct 1999 09:46:55 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id KAA04335; Mon, 25 Oct 1999 10:46:54 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA13773; Mon, 25 Oct 1999 10:46:53 -0600 Date: Mon, 25 Oct 1999 10:46:53 -0600 Message-Id: <199910251646.KAA13773@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910240608.AAA34462@harmony.village.org> References: <199910240608.AAA34462@harmony.village.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Consider the following situation. There is a driver talking to a > device. An unmasked interrupt happens and the device is now gone. > How does the driver know to stop what it is doing and respond to this > disappearance in a sane way? You can do what all the other OS's attempt to do, and not worry about it. On Win98/Linux, they allow the system to hang if the user ejects the card w/out properly shutting it down. So, if you do a reject on the card and something bad happens, it hangs. Yes, this isn't the best solution, but I don't believe there is a 'best' solution, or a good solution. That it happens to work some of the is good luck, not necessarily good design. In other words, I don't think a hardware solution exists. PHK and I have talked a 'bit' about this problem, and he's convinced me (in time) that it not a problem that can be solved completely. IMO, you can't sufficiently abstract it from the device, and each and every device driver requires alot of specific code that overly complicates/obfuscates the drivers in the tree. The *real* solution is to do the same kind of thing with PCCARD's that CDROM's drivers do, and not allow anyone to 'eject' the device until it's been shutdown properly, which allows the device driver to shut itself down *while* the hardware still exists. Unfortunately, this solution won't work completely due to missing hardware support. > This sort of situation comes up in the pccard code. When someone > ejects the card, an interrupt fires. If I were to remove the device > from the tree in the interrupt handler, I can invalidate the softc > that the driver is still using by freeing it. Actually, not always. You'll not always know that the device is gone when the driver is removed from the tree. It's possible (very probable) that the device may be in the process of servicing the interrupt *just* as the driver is removed, so what happens then? The code as written is trying to read from non-existing ports/memory locations, and can hang waiting for a result, or loop forever if it gets bad information. This is one of many 'races' that can not be solved w/out hardware support, since there's no way of controlling the removal of the hardware so that the software can 'clean up' safely. This is mostly independat of the softc stuff, which is BSD specific. > It is my understanding that the pccard hardware still still exist for > a period of time after the card is ejected (since it takes some period > of time to move from the pins that caused the interrupt to the > power/control/data pins being disabled). I don't know if this is > true, or if true what the period of time is. Not true at all. Otherwise, the 'hardware' would have to emulate the functionality of every card that was once in the slot, and respond in the same fashion. :( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 11:23:41 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8981114A01 for ; Mon, 25 Oct 1999 11:22:54 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA06334 for ; Mon, 25 Oct 1999 20:22:50 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA15769 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 20:22:49 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A88C514A1E for ; Mon, 25 Oct 1999 11:21:50 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA31289; Mon, 25 Oct 1999 12:21:45 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA41899; Mon, 25 Oct 1999 12:22:31 -0600 (MDT) Message-Id: <199910251822.MAA41899@harmony.village.org> To: nate@mt.sri.com (Nate Williams) Subject: Re: Racing interrupts Cc: arch@freebsd.org In-reply-to: Your message of "Mon, 25 Oct 1999 10:46:53 MDT." <199910251646.KAA13773@mt.sri.com> References: <199910251646.KAA13773@mt.sri.com> <199910240608.AAA34462@harmony.village.org> Date: Mon, 25 Oct 1999 12:22:31 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199910251646.KAA13773@mt.sri.com> Nate Williams writes: : Not true at all. Otherwise, the 'hardware' would have to emulate the : functionality of every card that was once in the slot, and respond in : the same fashion. :( OK. Somehow I had it in my head that pccard slots had pins of differing lenght and the short ones were used to trigger interrupts a fraction of a second before the card itself went dead due to the address/data pins going away. This is one reason that I want each driver in its own thread and that the interrupt that says the card is gone to effectively do a longjump to a "You are now gone, don't touch hardware, but cleanup the best you can" routine. However, I'm not sure what this would do to driver complexity. I also know that it may be fraught with problems because you'd need one thread per card and even then some drivers check all units on an interrupt.... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 11:28:52 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 73CAB14A01 for ; Mon, 25 Oct 1999 11:28:26 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA06412 for ; Mon, 25 Oct 1999 20:28:23 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA15799 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 20:28:23 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 4320E14A01 for ; Mon, 25 Oct 1999 11:27:35 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id MAA05202; Mon, 25 Oct 1999 12:27:31 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA14189; Mon, 25 Oct 1999 12:27:30 -0600 Date: Mon, 25 Oct 1999 12:27:30 -0600 Message-Id: <199910251827.MAA14189@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: nate@mt.sri.com (Nate Williams), arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910251822.MAA41899@harmony.village.org> References: <199910251646.KAA13773@mt.sri.com> <199910240608.AAA34462@harmony.village.org> <199910251822.MAA41899@harmony.village.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : Not true at all. Otherwise, the 'hardware' would have to emulate the > : functionality of every card that was once in the slot, and respond in > : the same fashion. :( > > OK. Somehow I had it in my head that pccard slots had pins of > differing lenght and the short ones were used to trigger interrupts a > fraction of a second before the card itself went dead due to the > address/data pins going away. Possibly, but the races still exist, and you can still get in a position where the hardware is gone. (I've verified this, having done alot of the work in the old pccard on suspend/resume.) > This is one reason that I want each driver in its own thread and that > the interrupt that says the card is gone to effectively do a longjump > to a "You are now gone, don't touch hardware, but cleanup the best you > can" routine. However, I'm not sure what this would do to driver > complexity. According to Sean Fagan, Stratus did in fact go to these kinds of lengths to make suspend/resume*insert/eject work, but it required re-writing/re-coding all of the drivers to support. It's certainly not impossible, but it does make the drivers that much more complex. And, (not to disagree with Sean), I don't see how you fix all the problems, simply because at some point you must assume the hardware exists, and if it disappears in the middle of an operation without any way of knowing that it's gone, how can you recover from it? When someone removes the bridge away from you while you're walking across the chasm, how can you be expected to 'recover' from it? ;) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 11:44:12 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A506414A1E for ; Mon, 25 Oct 1999 11:43:44 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA06569 for ; Mon, 25 Oct 1999 20:43:37 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA15898 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 20:43:37 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 02B4414A1E for ; Mon, 25 Oct 1999 11:40:24 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA31357; Mon, 25 Oct 1999 12:40:21 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA42028; Mon, 25 Oct 1999 12:41:07 -0600 (MDT) Message-Id: <199910251841.MAA42028@harmony.village.org> To: mjacob@feral.com Subject: Re: Racing interrupts Cc: arch@freebsd.org In-reply-to: Your message of "Sun, 24 Oct 1999 20:26:13 PDT." References: Date: Mon, 25 Oct 1999 12:41:07 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Matthew Jacob writes: : Presumably the interrupt that notifies one that a card has been pulled is : actually then managed by the bus device driver for that bus. This should : ensure that the the bus nexus controlller is notified that the state of : the hardware is changed. Yes. That is correct. : This does nothing for threads that were active at the time of the : interrupt. In this case, either the hardware is sane enough to continue to : provide some rational non-faulting access (in the case of memory mapping), : or you have to design a framework such that when the interrupt occurs, and : the nexus driver now knows how to remap any memory mappings so that a safe : non-faulting (if nonsensical) access can occur. Then some additional : mechanism which notifies the actual node driver that things have changed : will be invoked. Hmmm. I could do this, but do not know of any way of mapping I/O ports sanely. The problem appears to be driver busy waits for bits to become active. At least that's what it appears to be in the few I've seen. Most of the problems would be solved if I could detach the device before unmapping the interrupts, which is the part I needed to think about... Or rather look hard at the code to see why it is doing what it is doing and fix it... : For systems I'm more familiar with, explicit obligate parent-child : relationships have these specific notification mechanisms specified on a : per parent-child type basis. It's hard to generalize such mechanisms into : a usable general event notification mechanism because each bus has : different possible async events. A PC cardbus has removal/insertion, a : fibre channel arbitrated loop has LIP and then (re)arbitration for : AL_PAs- who knows what Compact PCI provides? : : What does newbus provide for this? newbus provides methods, but that is about it.. However, methods are easily ignored/defaulted so one can send arbitrary method call message to a tree or subtree and have sane things happen. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 11:51:21 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3C39F14CAF for ; Mon, 25 Oct 1999 11:51:10 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA06667 for ; Mon, 25 Oct 1999 20:51:07 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA15965 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 20:51:07 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 0EE2B15203 for ; Mon, 25 Oct 1999 11:50:01 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA31393; Mon, 25 Oct 1999 12:49:59 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA42106; Mon, 25 Oct 1999 12:50:45 -0600 (MDT) Message-Id: <199910251850.MAA42106@harmony.village.org> To: nate@mt.sri.com (Nate Williams) Subject: Re: Racing interrupts Cc: arch@freebsd.org In-reply-to: Your message of "Mon, 25 Oct 1999 12:27:30 MDT." <199910251827.MAA14189@mt.sri.com> References: <199910251827.MAA14189@mt.sri.com> <199910251646.KAA13773@mt.sri.com> <199910240608.AAA34462@harmony.village.org> <199910251822.MAA41899@harmony.village.org> Date: Mon, 25 Oct 1999 12:50:45 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199910251827.MAA14189@mt.sri.com> Nate Williams writes: : Possibly, but the races still exist, and you can still get in a position : where the hardware is gone. (I've verified this, having done alot of : the work in the old pccard on suspend/resume.) OK. So there is a small window there, but nothing that can be counted upon. One must therefore assume that the hardware is gone when the interrupt comes in... : According to Sean Fagan, Stratus did in fact go to these kinds of : lengths to make suspend/resume*insert/eject work, but it required : re-writing/re-coding all of the drivers to support. I believe it. Suspend/resume isn't too bad if you can do it from softclock and then raise SPL to a high level, detach all devices then remove power from them. Unfielded interrupts may result, but nothing worse. Card eject is a much more urgent condition in that you can't put it off for a little while to give people a chance to get out of interrupt handlers and such. : It's certainly not impossible, but it does make the drivers that much : more complex. And, (not to disagree with Sean), I don't see how you : fix all the problems, simply because at some point you must assume the : hardware exists, and if it disappears in the middle of an operation : without any way of knowing that it's gone, how can you recover from it? Yes. W/o explicit checks for 'am I gone' it is very hard, and where do you make them, and there is still a tiny race between the checking for am I gone and the touching of hardware. These races can be made so small as to be hard to lose. That's one reason I think that having some way to terminate the current thread of execution at any instruction with a simple callback saying, "I killed your driver thread, cope with the loss of hardware" is about as good as we're going to get. I know that we don't have kernel threads, let alone driver threads so this isn't a viable option at this time, but conceptually that's what you'll have to do, I think. : When someone removes the bridge away from you while you're walking : across the chasm, how can you be expected to 'recover' from it? ;) By hanging onto the bridge :-) Or registering a SIGBRIDGE handler and hoping that the 'chute deploys in time :-). That does bring the overhead of carrying a parachute all the time on the off chance that one of the zillion bridges you walk over might cause problems. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 11:54:15 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 73EF115216 for ; Mon, 25 Oct 1999 11:53:59 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA06693 for ; Mon, 25 Oct 1999 20:53:53 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA15993 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 20:53:52 +0200 (MET DST) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 76AA315216 for ; Mon, 25 Oct 1999 11:53:23 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA01130; Mon, 25 Oct 1999 11:53:17 -0700 Date: Mon, 25 Oct 1999 11:53:21 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910251841.MAA42028@harmony.village.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 Mon, 25 Oct 1999, Warner Losh wrote: > In message Matthew Jacob writes: > : Presumably the interrupt that notifies one that a card has been pulled is > : actually then managed by the bus device driver for that bus. This should > : ensure that the the bus nexus controlller is notified that the state of > : the hardware is changed. > > Yes. That is correct. > > : This does nothing for threads that were active at the time of the > : interrupt. In this case, either the hardware is sane enough to continue to > : provide some rational non-faulting access (in the case of memory mapping), > : or you have to design a framework such that when the interrupt occurs, and > : the nexus driver now knows how to remap any memory mappings so that a safe > : non-faulting (if nonsensical) access can occur. Then some additional > : mechanism which notifies the actual node driver that things have changed > : will be invoked. > > Hmmm. I could do this, but do not know of any way of mapping I/O > ports sanely. The problem appears to be driver busy waits for bits to I/O instructions don't cause faults if the port doesn't exist, right? They just are /dev/null for writes and return nonsense for reads. I suppose that if a driver is polling an I/O port, and it knows it's on a bus where this I/O port can go away, it should check for other status, no? Heck, you shouldn't have drivers poll forever anyway. > become active. At least that's what it appears to be in the few I've > seen. Most of the problems would be solved if I could detach the > device before unmapping the interrupts, which is the part I needed to > think about... Or rather look hard at the code to see why it is doing > what it is doing and fix it... > > : For systems I'm more familiar with, explicit obligate parent-child > : relationships have these specific notification mechanisms specified on a > : per parent-child type basis. It's hard to generalize such mechanisms into > : a usable general event notification mechanism because each bus has > : different possible async events. A PC cardbus has removal/insertion, a > : fibre channel arbitrated loop has LIP and then (re)arbitration for > : AL_PAs- who knows what Compact PCI provides? > : > : What does newbus provide for this? > > newbus provides methods, but that is about it.. However, methods are > easily ignored/defaulted so one can send arbitrary method call message > to a tree or subtree and have sane things happen. > Well, it sounds like you can do what you want then! :-) Except you seem to want a more general event mechanism so that drivers can know that their resources may have changed? Now that I think about it, this could possibly be a useful extension but would require a callback entry- and callback entries are bad for loadable drivers. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 11:59: 7 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2F9D415216 for ; Mon, 25 Oct 1999 11:58:49 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA06746 for ; Mon, 25 Oct 1999 20:58:46 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA16048 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 20:58:46 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id C3F1615216 for ; Mon, 25 Oct 1999 11:57:31 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id MAA05525; Mon, 25 Oct 1999 12:57:25 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA14453; Mon, 25 Oct 1999 12:57:24 -0600 Date: Mon, 25 Oct 1999 12:57:24 -0600 Message-Id: <199910251857.MAA14453@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: nate@mt.sri.com (Nate Williams), arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910251850.MAA42106@harmony.village.org> References: <199910251827.MAA14189@mt.sri.com> <199910251646.KAA13773@mt.sri.com> <199910240608.AAA34462@harmony.village.org> <199910251822.MAA41899@harmony.village.org> <199910251850.MAA42106@harmony.village.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : Possibly, but the races still exist, and you can still get in a position > : where the hardware is gone. (I've verified this, having done alot of > : the work in the old pccard on suspend/resume.) > > OK. So there is a small window there, but nothing that can be counted > upon. One must therefore assume that the hardware is gone when the > interrupt comes in... Agreed. Sean also brought up the fact that it was necessary for Stratus to do this in the case of 'failed' hardware, which is a big deal not to hang your kernel when you're advertising yourself as fault-tolerant. :) > : It's certainly not impossible, but it does make the drivers that much > : more complex. And, (not to disagree with Sean), I don't see how you > : fix all the problems, simply because at some point you must assume the > : hardware exists, and if it disappears in the middle of an operation > : without any way of knowing that it's gone, how can you recover from it? > > Yes. W/o explicit checks for 'am I gone' it is very hard, and where > do you make them, and there is still a tiny race between the checking > for am I gone and the touching of hardware. These races can be made > so small as to be hard to lose. The 'am I gone' race is a big one (IMO), and instead of trying to minimize that race (which I don't think we can minimize much at all), I think the solution (which is much more complex) is to re-write the device drivers to never do busy-wait loops, never-ending timeouts, etc... Unfortunately, this may require changes to some basic FreeBSD assumptions (timeouts in particular). Do tsleep/wakeup provide for a 'default' timeout and notification? > That's one reason I think that having > some way to terminate the current thread of execution at any > instruction with a simple callback saying, "I killed your driver > thread, cope with the loss of hardware" is about as good as we're > going to get. This requiers changes to all drivers to not expect that a piece of hardware exists. And, if the thread is never given the indication that the hardware is gone (think fast interrupts), it still must deal with the fact that the hardware *may* be gone. It would also have a nice side-effect of making FreeBSD much more tolerant of failing hardware, although I'm not sure we would need to go the the lengths that a company like Stratus does. They don't have to support the wide variety of hardware that FreeBSD does. > : When someone removes the bridge away from you while you're walking > : across the chasm, how can you be expected to 'recover' from it? ;) > > By hanging onto the bridge :-) Or registering a SIGBRIDGE handler and > hoping that the 'chute deploys in time :-). That implies that you are informed that the bridge is gone, instead of finding out about it from striking the ground w/out a net. :( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 12: 4:34 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 137DF15220 for ; Mon, 25 Oct 1999 12:04:16 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA06788 for ; Mon, 25 Oct 1999 21:04:06 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA16087 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 21:04:06 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id DA69D1522C for ; Mon, 25 Oct 1999 12:02:36 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA05582; Mon, 25 Oct 1999 13:02:31 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA14532; Mon, 25 Oct 1999 13:02:30 -0600 Date: Mon, 25 Oct 1999 13:02:30 -0600 Message-Id: <199910251902.NAA14532@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mjacob@feral.com Cc: Warner Losh , arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: References: <199910251841.MAA42028@harmony.village.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > : This does nothing for threads that were active at the time of the > > : interrupt. In this case, either the hardware is sane enough to continue to > > : provide some rational non-faulting access (in the case of memory mapping), > > : or you have to design a framework such that when the interrupt occurs, and > > : the nexus driver now knows how to remap any memory mappings so that a safe > > : non-faulting (if nonsensical) access can occur. Then some additional > > : mechanism which notifies the actual node driver that things have changed > > : will be invoked. > > > > Hmmm. I could do this, but do not know of any way of mapping I/O > > ports sanely. The problem appears to be driver busy waits for bits to > > I/O instructions don't cause faults if the port doesn't exist, right? They > just are /dev/null for writes and return nonsense for reads. How do you differentiate between 'good' reads and 'nonsensical' reads? > I suppose that if a driver is polling an I/O port, and it knows it's on a > bus where this I/O port can go away, it should check for other status, no? > Heck, you shouldn't have drivers poll forever anyway. Agreed, but these sort of assumptions exist today, and re-writing the driver is non-trivial, and adds additional complexity, especially since FreeBSD doesn't have the infrastructure to deal with these kinds of changes (yet). 1) How do you recognize 'garbage'? 2) What do you do when you determine a piece of hardware is gone/bad? 3) What about dependencies? (If the disk is bad, do you unmount the FS, flush the buffers, etc...?) Error handling is *HARD WORK*, and it's difficult to make a generic infrastructure to deal with all of the different kinds of errors that may occur. It's alot easier to use the standard FreeBSD approach to the problem. "You've got broken hardware, fix it and FreeBSD will work better." :( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 12:14:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 407A215235 for ; Mon, 25 Oct 1999 12:13:57 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA06887 for ; Mon, 25 Oct 1999 21:13:46 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA16148 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 21:13:45 +0200 (MET DST) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9ADA014CBB for ; Mon, 25 Oct 1999 12:13:18 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id MAA01266; Mon, 25 Oct 1999 12:13:05 -0700 Date: Mon, 25 Oct 1999 12:13:08 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Nate Williams Cc: Warner Losh , arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910251902.NAA14532@mt.sri.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 Mon, 25 Oct 1999, Nate Williams wrote: > > > : This does nothing for threads that were active at the time of the > > > : interrupt. In this case, either the hardware is sane enough to continue to > > > : provide some rational non-faulting access (in the case of memory mapping), > > > : or you have to design a framework such that when the interrupt occurs, and > > > : the nexus driver now knows how to remap any memory mappings so that a safe > > > : non-faulting (if nonsensical) access can occur. Then some additional > > > : mechanism which notifies the actual node driver that things have changed > > > : will be invoked. > > > > > > Hmmm. I could do this, but do not know of any way of mapping I/O > > > ports sanely. The problem appears to be driver busy waits for bits to > > > > I/O instructions don't cause faults if the port doesn't exist, right? They > > just are /dev/null for writes and return nonsense for reads. > > How do you differentiate between 'good' reads and 'nonsensical' reads? That's the node driver's problem. > > > I suppose that if a driver is polling an I/O port, and it knows it's on a > > bus where this I/O port can go away, it should check for other status, no? > > Heck, you shouldn't have drivers poll forever anyway. > > Agreed, but these sort of assumptions exist today, and re-writing the > driver is non-trivial, and adds additional complexity, especially since > FreeBSD doesn't have the infrastructure to deal with these kinds of > changes (yet). > > 1) How do you recognize 'garbage'? Again, this isn't the main point. The main point is that if the h/w resource is invalidated, node drivers have to know how to check for this (and leave enough headroom to do so), and the system can't panic because somebody physically changed something (other than the power switch, duh). > 2) What do you do when you determine a piece of hardware is gone/bad? "Bad" hardware is a separate issue, really. But if a piece of hardware goes, and there is some kind of notification by some other controlling hardware, it's just sloppy architecture to not make use of that information. If there is no notification, then you lose (and either should get better h/w or accept a wedged system). > 3) What about dependencies? (If the disk is bad, do you unmount the FS, > flush the buffers, etc...?) That's already handled (mishandled, actually) in CAM by the pack invalidation code. > > Error handling is *HARD WORK*, and it's difficult to make a generic > infrastructure to deal with all of the different kinds of errors that > may occur. > > It's alot easier to use the standard FreeBSD approach to the problem. > "You've got broken hardware, fix it and FreeBSD will work better." :( Then FreeBSD will never be a serious server solution, and I for one would quit wasting my time on a Linux wannabe. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 12:16:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 67C4D15229 for ; Mon, 25 Oct 1999 12:16:28 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA06934 for ; Mon, 25 Oct 1999 21:16:25 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA16174 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 21:16:25 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 581901521E for ; Mon, 25 Oct 1999 12:15:15 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA05711; Mon, 25 Oct 1999 13:15:11 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA14613; Mon, 25 Oct 1999 13:15:09 -0600 Date: Mon, 25 Oct 1999 13:15:09 -0600 Message-Id: <199910251915.NAA14613@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mjacob@feral.com Cc: Nate Williams , Warner Losh , arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: References: <199910251902.NAA14532@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It's alot easier to use the standard FreeBSD approach to the problem. > > "You've got broken hardware, fix it and FreeBSD will work better." :( > > Then FreeBSD will never be a serious server solution, and I for one would > quit wasting my time on a Linux wannabe. Linux wannabe? Cheap shot, and completely uncalled for, especially since Linux is no better at this than FreeBSD, and often-times *MUCH* worse. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 12:17:31 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 05D8615263 for ; Mon, 25 Oct 1999 12:17:20 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA06948 for ; Mon, 25 Oct 1999 21:17:15 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA16201 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 21:17:14 +0200 (MET DST) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1EACF1521E for ; Mon, 25 Oct 1999 12:16:24 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id MAA01297; Mon, 25 Oct 1999 12:16:15 -0700 Date: Mon, 25 Oct 1999 12:16:19 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Nate Williams Cc: Warner Losh , arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910251915.NAA14613@mt.sri.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 Feh. Okay, maybe a cheapshot. Sorry. But the argument "Things are just fine the way they are and users will cope" pushes my buttons a bit... On Mon, 25 Oct 1999, Nate Williams wrote: > > > It's alot easier to use the standard FreeBSD approach to the problem. > > > "You've got broken hardware, fix it and FreeBSD will work better." :( > > > > Then FreeBSD will never be a serious server solution, and I for one would > > quit wasting my time on a Linux wannabe. > > Linux wannabe? Cheap shot, and completely uncalled for, especially > since Linux is no better at this than FreeBSD, and often-times *MUCH* > worse. > > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 12:22: 2 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A6C54152B6 for ; Mon, 25 Oct 1999 12:21:47 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA06993 for ; Mon, 25 Oct 1999 21:21:44 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA16251 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 21:21:44 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 1B9821522F for ; Mon, 25 Oct 1999 12:21:17 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA05790; Mon, 25 Oct 1999 13:21:07 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA14719; Mon, 25 Oct 1999 13:21:06 -0600 Date: Mon, 25 Oct 1999 13:21:06 -0600 Message-Id: <199910251921.NAA14719@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mjacob@feral.com Cc: Nate Williams , Warner Losh , arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: References: <199910251915.NAA14613@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Feh. Okay, maybe a cheapshot. Sorry. But the argument "Things are just > fine the way they are and users will cope" pushes my buttons a bit... I didn't agree that 'things are just fine the way they are', I simply stated that too often the standard approach to the problem is to state 'your hardware is broken, fix it'. I don't like this stand (although have used it myself on many occasions), but I suspect it will be the solution that is found, given the lack of resources. Are you willing to spend the time to design/develop a working error handling system for FreeBSD? Standing on the sidelines and stating that it's broken w/out spending any resources to make it better is a bigger crime in my opinion than not having the system in the first place.... Nate > > > On Mon, 25 Oct 1999, Nate Williams wrote: > > > > > It's alot easier to use the standard FreeBSD approach to the problem. > > > > "You've got broken hardware, fix it and FreeBSD will work better." :( > > > > > > Then FreeBSD will never be a serious server solution, and I for one would > > > quit wasting my time on a Linux wannabe. > > > > Linux wannabe? Cheap shot, and completely uncalled for, especially > > since Linux is no better at this than FreeBSD, and often-times *MUCH* > > worse. > > > > > > > > Nate > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 12:44:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B449514C9A for ; Mon, 25 Oct 1999 12:44:32 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07226 for ; Mon, 25 Oct 1999 21:44:29 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA16392 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 21:44:29 +0200 (MET DST) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0EC8A1522F for ; Mon, 25 Oct 1999 12:36:17 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id MAA01439; Mon, 25 Oct 1999 12:36:11 -0700 Date: Mon, 25 Oct 1999 12:36:15 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Nate Williams Cc: Warner Losh , arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910251921.NAA14719@mt.sri.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 > > Feh. Okay, maybe a cheapshot. Sorry. But the argument "Things are just > > fine the way they are and users will cope" pushes my buttons a bit... > > I didn't agree that 'things are just fine the way they are', I simply > stated that too often the standard approach to the problem is to state > 'your hardware is broken, fix it'. > > I don't like this stand (although have used it myself on many > occasions), but I suspect it will be the solution that is found, given > the lack of resources. > > Are you willing to spend the time to design/develop a working error > handling system for FreeBSD? Standing on the sidelines and stating that > it's broken w/out spending any resources to make it better is a bigger > crime in my opinion than not having the system in the first place.... Warner asked a question. I expressed an opinion. This is the forum for such opinions. If I have time and it is appropriate for me to do so, I will help design and implement such a system for FreeBSD. I'm not currently working directly on subsystems that have intermediate mappings that can go away, but I *am* involved in both the CAM design and the stuff Justin is talking about for incorporating CAM3, so I believe that your attempts to tag me as a criminal don't apply. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 12:46:57 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 972761525D for ; Mon, 25 Oct 1999 12:46:46 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07274 for ; Mon, 25 Oct 1999 21:46:43 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA16470 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 21:46:43 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A694B14A2B for ; Mon, 25 Oct 1999 12:46:22 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA31685; Mon, 25 Oct 1999 13:46:19 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA42593; Mon, 25 Oct 1999 13:47:06 -0600 (MDT) Message-Id: <199910251947.NAA42593@harmony.village.org> To: mjacob@feral.com Subject: Re: Racing interrupts Cc: Nate Williams , arch@freebsd.org In-reply-to: Your message of "Mon, 25 Oct 1999 12:36:15 PDT." References: Date: Mon, 25 Oct 1999 13:47:06 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Can we keep this a little more technical. Both Nate Williams and Matthew Jacob have had good things to say about how to solve this problem, and the extent to which one can solve this problem. Can we limit future messages to this topic and take the other stuff to private mail. I appreciate what everyone has had to say about this problem and will keep it in mind moving forward. pccard eject is fundamentally broken in many ways, but we must cope with it at some point. Explaining why things suck is useful, but be careful about confusing the explaination for an excuse to not do better. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 12:52: 0 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D03F3152D8 for ; Mon, 25 Oct 1999 12:51:32 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07324 for ; Mon, 25 Oct 1999 21:51:30 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA16519 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 21:51:29 +0200 (MET DST) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0964D15208 for ; Mon, 25 Oct 1999 12:49:38 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id MAA01554; Mon, 25 Oct 1999 12:49:25 -0700 Date: Mon, 25 Oct 1999 12:49:28 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: Nate Williams , arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910251947.NAA42593@harmony.village.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 Nate && I already smooched and made up in private email. Sorry for getting cranky.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 15:29:17 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5E16714C4E for ; Mon, 25 Oct 1999 15:29:13 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA08818 for ; Tue, 26 Oct 1999 00:29:12 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA17359 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 00:29:11 +0200 (MET DST) Received: by hub.freebsd.org (Postfix, from userid 758) id ADB3114C4E; Mon, 25 Oct 1999 15:29:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9B76F1CD43E; Mon, 25 Oct 1999 15:29:00 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Mon, 25 Oct 1999 15:29:00 -0700 (PDT) From: Kris Kennaway To: Pascal Hofstee Cc: freebsd-hackers@freebsd.org, arch@freebsd.org Subject: Re: module names 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 This kind of stuff is better suited to the arch mailing list..cross-posting. Kris On Tue, 26 Oct 1999, Pascal Hofstee wrote: > Hi, > > With the recent addition of more and more KLDs to the /modules directory i > was wondering if perhaps it would be a good idea to name these modules > more consistantly: > > if_* : For all network modules (done already) > ng_* : For all netgraph related modules (done already) > fs_* : For all filesystem modules > saver_* : For all screensavers (probably would prefer a shorter prefix) > emu_* : For binary compatibilty modules like linux/ibcs2/svr4 > > of course this is just a suggestion ... just thought i would voice it > here. > > -------------------- > Pascal Hofstee - daeron@shadowmere.student.utwente.nl > > -----BEGIN GEEK CODE BLOCK----- > Version: 3.1 > GCS d- s+: a-- C++ UB++++ P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP-- > t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+ > ------END GEEK CODE BLOCK------ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > ---- XOR for AES -- join the campaign! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 17:56:45 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 179A314D92 for ; Mon, 25 Oct 1999 17:56:42 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA10176 for ; Tue, 26 Oct 1999 02:56:40 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA17965 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 02:56:40 +0200 (MET DST) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 4604B14D92 for ; Mon, 25 Oct 1999 17:56:29 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id RAA06512; Mon, 25 Oct 1999 17:56:28 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd006487; Mon Oct 25 17:56:20 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id RAA20467; Mon, 25 Oct 1999 17:56:19 -0700 (MST) From: Terry Lambert Message-Id: <199910260056.RAA20467@usr06.primenet.com> Subject: Re: Racing interrupts To: nate@mt.sri.com Date: Tue, 26 Oct 1999 00:56:19 +0000 (GMT) Cc: imp@village.org, arch@freebsd.org In-Reply-To: <199910251646.KAA13773@mt.sri.com> from "Nate Williams" at Oct 25, 99 10:46:53 am X-Mailer: ELM [version 2.4 PL25] 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 > > Consider the following situation. There is a driver talking to a > > device. An unmasked interrupt happens and the device is now gone. > > How does the driver know to stop what it is doing and respond to this > > disappearance in a sane way? > > You can do what all the other OS's attempt to do, and not worry about > it. On Win98/Linux, they allow the system to hang if the user ejects > the card w/out properly shutting it down. > > So, if you do a reject on the card and something bad happens, it hangs. > Yes, this isn't the best solution, but I don't believe there is a 'best' > solution, or a good solution. That it happens to work some of the is > good luck, not necessarily good design. A lot of these OSs, Windows especially, provide a utility for managing this. In Windows, there's a "PCCARD" control panel that you can use to "stop" the cards before removing them. In addition, most card vendors who supply drivers dock a little application in the task bar (e.g. the Linksys driver docks a tiny icon, whose only menu entry is "stop the linksys ethernet card". Both of these are kludges for bad up front design, and I think they should be tossed out without further consideration, even as a means of whining at the user to put the card back so it can be "shutdown properly". FreeBSD has no concept of a session manager, which could be used in order to get the whine from the kernel to user space (and perhaps get a response from the user). > In other words, I don't think a hardware solution exists. PHK and I > have talked a 'bit' about this problem, and he's convinced me (in time) > that it not a problem that can be solved completely. IMO, you can't > sufficiently abstract it from the device, and each and every device > driver requires alot of specific code that overly complicates/obfuscates > the drivers in the tree. I disagree. Windows will actually pop up a dialog to complain about a card being ejected while it is active ("started"). The system will not crash as a result of this. Effectively, the driver is "frozen", and the usual recommended pallative is to reinsert the card, and click "Shutdown" (or "cancel" to leave the card running, or "OK" to terminate the card unceremoniously). I think this is really a driver API issue, more than anything else. To quote one of Poul's favorite hobby horses, which I definitely agree with, the driver need notifications for each close, not just the final one, and all drivers need to be fixed to play by this rule. In addition, there is some need for interrupt masking, and a handler abort for an active interrupt currently in the driver. In effect, this means the ability to force the moral equivalent of a longjmp to the interrupt dispatch code. So long as resources are not allocated (a no-no in an interrupt handler), and are properly committed (this is a coding style issue, more than anything else), it should be workable. One could easily imagine that the "longjmp" would result in a special "device departure" entry point being entered. The only remaining issue would be decommiting partial resource commits. As a matter of coding style, this could be implemented either by preventing states other than a base state in the driver (this would be painful for driver writers, but only once), or by using a bitmap to track state over resource commits, so that the "device departure" handler can back them out (e.g. things like "this mbuf is in use", etc.). I think that, in the long run, our drivers could only benefit from this kind of attention, since the same work needs to be done at some point anyway to allow CPU reentrancy into the interrupt handling code, with the interrupt lock changing into an I/O address space lock, and a CPU-commit lock for committing an interrupt for handling by a given CPU in the SMP case (plus whatever masking is agreed upon for shared interrupts, etc.). > > This sort of situation comes up in the pccard code. When someone > > ejects the card, an interrupt fires. If I were to remove the device > > from the tree in the interrupt handler, I can invalidate the softc > > that the driver is still using by freeing it. > > Actually, not always. You'll not always know that the device is gone > when the driver is removed from the tree. It's possible (very probable) > that the device may be in the process of servicing the interrupt *just* > as the driver is removed, so what happens then? The code as written is > trying to read from non-existing ports/memory locations, and can hang > waiting for a result, or loop forever if it gets bad information. > > This is one of many 'races' that can not be solved w/out hardware > support, since there's no way of controlling the removal of the hardware > so that the software can 'clean up' safely. I think that you could handle this via the "longjmp" and resource commit state tracking, described above. It would be nive for PCI hot swap and other reasons to be able to deal with the departure and arrival of (replacement?) hardware automatically, so long as it can be done nicely, and you don't end up introducing warts in the process -- even if you do end up adding some restrictions on driver coding style, and the use of APIs. The overhead of the "longjmp" is practically that of a stack probe: that is, about one stack pointer store operation and a register checkpoint. Is FreeBSD going to have UDI support at some point? It has a "method" of dealing with this issue for PCI hot swap. > > It is my understanding that the pccard hardware still still exist for > > a period of time after the card is ejected (since it takes some period > > of time to move from the pins that caused the interrupt to the > > power/control/data pins being disabled). I don't know if this is > > true, or if true what the period of time is. > > Not true at all. Otherwise, the 'hardware' would have to emulate the > functionality of every card that was once in the slot, and respond in > the same fashion. :( Depending on being able to talk to an unplugged device is pretty much a bad idea, even if you have several milliseconds that you might be able to use to do the job. I don't think that allowing a driver servicing an interrupt at the time the card is unplugged to run to completion based on this theory is a good idea, in any case. You need to abort the interrupt in progress, if any, and back out any partially committed (and incomplete) state transitions on things like buffers owned by the kernel, not the device, etc.. 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 Oct 25 18: 4:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8E0D614C04 for ; Mon, 25 Oct 1999 18:04:32 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA10258 for ; Tue, 26 Oct 1999 03:04:32 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA18004 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 03:04:32 +0200 (MET DST) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 80B28152E4 for ; Mon, 25 Oct 1999 18:03:58 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id SAA29674; Mon, 25 Oct 1999 18:03:51 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpdAAAf8aW65; Mon Oct 25 18:03:43 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA21028; Mon, 25 Oct 1999 18:03:45 -0700 (MST) From: Terry Lambert Message-Id: <199910260103.SAA21028@usr06.primenet.com> Subject: Re: Racing interrupts To: nate@mt.sri.com Date: Tue, 26 Oct 1999 01:03:45 +0000 (GMT) Cc: imp@village.org, arch@freebsd.org In-Reply-To: <199910251827.MAA14189@mt.sri.com> from "Nate Williams" at Oct 25, 99 12:27:30 pm X-Mailer: ELM [version 2.4 PL25] 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 > > This is one reason that I want each driver in its own thread and that > > the interrupt that says the card is gone to effectively do a longjump > > to a "You are now gone, don't touch hardware, but cleanup the best you > > can" routine. However, I'm not sure what this would do to driver > > complexity. > > According to Sean Fagan, Stratus did in fact go to these kinds of > lengths to make suspend/resume*insert/eject work, but it required > re-writing/re-coding all of the drivers to support. > > It's certainly not impossible, but it does make the drivers that much > more complex. And, (not to disagree with Sean), I don't see how you > fix all the problems, simply because at some point you must assume the > hardware exists, and if it disappears in the middle of an operation > without any way of knowing that it's gone, how can you recover from it? > > When someone removes the bridge away from you while you're walking > across the chasm, how can you be expected to 'recover' from it? ;) In a puff of greasy orange smoke, you appear at the side of the chasm you just left before the bridge went away. 8-). I really, really don't think there are that many drivers, especially for PCCARD/PCMCIA attached devices, that keep a whole heck of a lot of state, and so I think the impact on the drivers would be rather small, actually. For drivers that have a lot of state -- well, what the heck do they need all that state for, it makes things difficult for kernel/driver CPU rentrancy! Even so, I think a 32 bit value capable of tracking the state transitions, and checkpointing of dangling pointers into volatile variables before they are made to dangle, should be enough. Really the only state that you need to recover is state in objects that are owned by the system (e.g. mbuf's, etc.) that you need to recover for a "nice" shutdown. In many cases, you could intentionally "leak", as an intentional strategy, until the drivers are brought up to spec. (I dislike this, since it seems rather "Windowsy", but it would work as a short term bridge solution). 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 Oct 25 18: 5:31 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9704D14C04 for ; Mon, 25 Oct 1999 18:05:27 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA10275 for ; Tue, 26 Oct 1999 03:05:26 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA18032 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 03:05:26 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 7F2A214C04 for ; Mon, 25 Oct 1999 18:05:18 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id TAA08901; Mon, 25 Oct 1999 19:05:04 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id TAA16714; Mon, 25 Oct 1999 19:05:03 -0600 Date: Mon, 25 Oct 1999 19:05:03 -0600 Message-Id: <199910260105.TAA16714@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910260056.RAA20467@usr06.primenet.com> References: <199910251646.KAA13773@mt.sri.com> <199910260056.RAA20467@usr06.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > In other words, I don't think a hardware solution exists. PHK and I > > have talked a 'bit' about this problem, and he's convinced me (in time) > > that it not a problem that can be solved completely. IMO, you can't > > sufficiently abstract it from the device, and each and every device > > driver requires alot of specific code that overly complicates/obfuscates > > the drivers in the tree. > > I disagree. Windows will actually pop up a dialog to complain > about a card being ejected while it is active ("started"). Sometimes it will. I Win95 it 'mostly works', and on '98 it sometimes works. Sometimes it hangs the box, sometimes it whines. > The system will not crash as a result of this. Not true, it will hang the system. I can show this if more proof is needed on my laptop. There is no software solution that will avoid all problems. [ Deleted rest of article since it is based on assumptions that I don't ascribe to... ] Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 18:10:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id DFA1A14C04 for ; Mon, 25 Oct 1999 18:10:16 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA10303 for ; Tue, 26 Oct 1999 03:10:15 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA18061 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 03:10:15 +0200 (MET DST) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id EB32014C04 for ; Mon, 25 Oct 1999 18:10:00 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id SAA01358; Mon, 25 Oct 1999 18:09:56 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpdAAAMOaOIc; Mon Oct 25 18:09:46 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA21444; Mon, 25 Oct 1999 18:09:40 -0700 (MST) From: Terry Lambert Message-Id: <199910260109.SAA21444@usr06.primenet.com> Subject: Re: Racing interrupts To: imp@village.org (Warner Losh) Date: Tue, 26 Oct 1999 01:09:39 +0000 (GMT) Cc: mjacob@feral.com, arch@freebsd.org In-Reply-To: <199910251841.MAA42028@harmony.village.org> from "Warner Losh" at Oct 25, 99 12:41:07 pm X-Mailer: ELM [version 2.4 PL25] 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 > : This does nothing for threads that were active at the time of the > : interrupt. In this case, either the hardware is sane enough to continue to > : provide some rational non-faulting access (in the case of memory mapping), > : or you have to design a framework such that when the interrupt occurs, and > : the nexus driver now knows how to remap any memory mappings so that a safe > : non-faulting (if nonsensical) access can occur. Then some additional > : mechanism which notifies the actual node driver that things have changed > : will be invoked. > > Hmmm. I could do this, but do not know of any way of mapping I/O > ports sanely. The problem appears to be driver busy waits for bits to > become active. At least that's what it appears to be in the few I've > seen. Most of the problems would be solved if I could detach the > device before unmapping the interrupts, which is the part I needed to > think about... Or rather look hard at the code to see why it is doing > what it is doing and fix it... Certain code won't be fixable like this, e.g. code that does what it does for say a PCMCIA attached floppy disk. Also, I think PIO based (polled) drivers might have a problem with this, whereas they wouldn't with a stack unwind. I think that if the inb/outb code (and bus settle code) was fitted with a lock, and you insisted on grabbing the lock at the nexus, then you potentially sidestep this issue when using a stack unwind approach. Since this is a rather necessary step to achieve better granularity SMP (multiple CPUs in interrupt code simultaneously), it's work that has to be done at some point, anyway. 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 Oct 25 18:13:11 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2C2F814C04 for ; Mon, 25 Oct 1999 18:13:09 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA10330 for ; Tue, 26 Oct 1999 03:13:09 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA18088 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 03:13:08 +0200 (MET DST) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 6C2F514C04 for ; Mon, 25 Oct 1999 18:12:57 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id SAA28564; Mon, 25 Oct 1999 18:12:45 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpdAAAxCaGV3; Mon Oct 25 18:12:37 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA21635; Mon, 25 Oct 1999 18:12:47 -0700 (MST) From: Terry Lambert Message-Id: <199910260112.SAA21635@usr06.primenet.com> Subject: Re: Racing interrupts To: imp@village.org (Warner Losh) Date: Tue, 26 Oct 1999 01:12:47 +0000 (GMT) Cc: nate@mt.sri.com, arch@freebsd.org In-Reply-To: <199910251850.MAA42106@harmony.village.org> from "Warner Losh" at Oct 25, 99 12:50:45 pm X-Mailer: ELM [version 2.4 PL25] 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 > Yes. W/o explicit checks for 'am I gone' it is very hard, and where > do you make them, and there is still a tiny race between the checking > for am I gone and the touching of hardware. These races can be made > so small as to be hard to lose. That's one reason I think that having > some way to terminate the current thread of execution at any > instruction with a simple callback saying, "I killed your driver > thread, cope with the loss of hardware" is about as good as we're > going to get. I know that we don't have kernel threads, let alone > driver threads so this isn't a viable option at this time, but > conceptually that's what you'll have to do, I think. This leaks, unless you track state, and if you track state, then you don't need to let the driver finish doing any diddling of the hardware, you can just arrest it at any time, with the only exception being an extra I/O bus "settle" cycle to protect yourself. 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 Oct 25 19:21:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4457414DEA for ; Mon, 25 Oct 1999 19:21:23 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA10835 for ; Tue, 26 Oct 1999 04:21:22 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA18342 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 04:21:21 +0200 (MET DST) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 5A23814DEA for ; Mon, 25 Oct 1999 19:21:16 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id TAA20353; Mon, 25 Oct 1999 19:21:06 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpdAAAjRaWTN; Mon Oct 25 19:21:03 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA26021; Mon, 25 Oct 1999 19:21:03 -0700 (MST) From: Terry Lambert Message-Id: <199910260221.TAA26021@usr06.primenet.com> Subject: Re: Racing interrupts To: nate@mt.sri.com Date: Tue, 26 Oct 1999 02:21:03 +0000 (GMT) Cc: tlambert@primenet.com, imp@village.org, arch@freebsd.org In-Reply-To: <199910260105.TAA16714@mt.sri.com> from "Nate Williams" at Oct 25, 99 07:05:03 pm X-Mailer: ELM [version 2.4 PL25] 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 disagree. Windows will actually pop up a dialog to complain > > about a card being ejected while it is active ("started"). > > Sometimes it will. I Win95 it 'mostly works', and on '98 it sometimes > works. Sometimes it hangs the box, sometimes it whines. > > > The system will not crash as a result of this. > > Not true, it will hang the system. I can show this if more proof is > needed on my laptop. There is no software solution that will avoid all > problems. > > [ > Deleted rest of article since it is based on assumptions that I don't > ascribe to... > ] I think that a driver that crashes the system as a result of the hardware being ejected is arguably a broken driver, from the standpoint of complying with the Windows removable device driver writers guide. I don't think that you can point at a particular failing instance, and then generalize from that about how it's supposed to work (as opposed to how it does work). 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 Oct 25 20:56:22 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 43C9314E38 for ; Mon, 25 Oct 1999 20:56:19 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA11418 for ; Tue, 26 Oct 1999 05:56:17 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA18575 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 05:56:16 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 3122C14E38 for ; Mon, 25 Oct 1999 20:56:09 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id VAA10218; Mon, 25 Oct 1999 21:56:06 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id VAA17204; Mon, 25 Oct 1999 21:56:05 -0600 Date: Mon, 25 Oct 1999 21:56:05 -0600 Message-Id: <199910260356.VAA17204@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910260221.TAA26021@usr06.primenet.com> References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think that a driver that crashes the system as a result of > the hardware being ejected is arguably a broken driver, from > the standpoint of complying with the Windows removable device > driver writers guide. Not true. The design simply does not take into account the fact that certain hardware/software interactions can not be coded in such a way to always recognize that the hardware is gone. The PCMCIA/PCCARD hardware/software specification did not take into account some very important design considerations. > I don't think that you can point at a particular failing instance, > and then generalize from that about how it's supposed to work (as > opposed to how it does work). My whole argument was based upon the reading of the specification and knowledge of hardware/software. My failing instance is to rebut your argument that 'just because it works on my box, it must therefore work'. It's broken by design, and although I can minimize the problems in software, there are still going to be races inherent in the design. The mostly working suspend/resume code in FreeBSD is *my* attempt to minimize those races, but stating that those races don't exist is foolish. I worked hard (and got lost of good help from Bruce) to make the window small, but in the end realized that it it couldn't be fully eliminated, and to minimize it further required re-writing many of the existing drivers, which would potentialy reduce performance and increase complexity with very little 'gain'. It works 98% of the time now, and to make it work 99% of the time required a lot of work for only 1% gain. That 1% of gain in 'stability' may cost 10-15% in terms of performance (requiring constant checks for the hardware being gone), which I deemed to be an acceptable cost/benefit. Now, you may consider it acceptable, and the costs may be better/worse than what I predicted, so feel free to hack away on the code and see what falls out. IMO the costs far outweigh the benefits... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 25 21:55:29 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B411C14DA7 for ; Mon, 25 Oct 1999 21:55:27 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA11815 for ; Tue, 26 Oct 1999 06:55:26 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA18774 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 06:55:26 +0200 (MET DST) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 8205D14DA7 for ; Mon, 25 Oct 1999 21:55:20 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11fydd-0000AX-00; Mon, 25 Oct 1999 22:55:14 -0600 Message-ID: <3815342E.F049539@softweyr.com> Date: Mon, 25 Oct 1999 22:55:10 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: Nate Williams , Warner Losh , arch@freebsd.org Subject: Re: Racing interrupts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > I'm not > currently working directly on subsystems that have intermediate mappings > that can go away, but I *am* involved in both the CAM design and the stuff > Justin is talking about for incorporating CAM3, so I believe that your > attempts to tag me as a criminal don't apply. And there is no such thing in the world as a hot-pluggable SCSI controller? Look again. ;^) -- "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 Tue Oct 26 8:18:55 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E91E114BF8 for ; Tue, 26 Oct 1999 08:18:47 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA21400 for ; Tue, 26 Oct 1999 17:18:42 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA21034 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 17:18:40 +0200 (MET DST) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 3FBAE14A03 for ; Tue, 26 Oct 1999 08:18:22 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id LAA27242; Tue, 26 Oct 1999 11:12:53 -0400 (EDT) Reply-To: Randell Jesup To: nate@mt.sri.com (Nate Williams) Cc: Terry Lambert , imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> From: Randell Jesup Date: 26 Oct 1999 11:14:19 +0000 In-Reply-To: Nate Williams's message of "Mon, 25 Oct 1999 21:56:05 -0600" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams writes: >> I think that a driver that crashes the system as a result of >> the hardware being ejected is arguably a broken driver, from >> the standpoint of complying with the Windows removable device >> driver writers guide. > >Not true. The design simply does not take into account the fact that >certain hardware/software interactions can not be coded in such a way to >always recognize that the hardware is gone. > >The PCMCIA/PCCARD hardware/software specification did not take into >account some very important design considerations. Such as? Of course, just because the MS spec says you should be able to pop out the hardware at any time doesn't mean you can't make software that says "you MUST shut down the driver before removing the card or you may lose all your work", but the problem with that is that it breaks the user's expectations, especially if all the other vendors handle it. Not to mention that it's a bad idea from a CHI standpoint. >It's broken by design, and although I can minimize the problems in >software, there are still going to be races inherent in the design. Then change the design. >The mostly working suspend/resume code in FreeBSD is *my* attempt to >minimize those races, but stating that those races don't exist is >foolish. I worked hard (and got lost of good help from Bruce) to >make the window small, but in the end realized that it it couldn't be >fully eliminated, and to minimize it further required re-writing many of >the existing drivers, which would potentialy reduce performance and >increase complexity with very little 'gain'. Why can't it be fully eliminated? >It works 98% of the time now, and to make it work 99% of the time >required a lot of work for only 1% gain. That 1% of gain in 'stability' >may cost 10-15% in terms of performance (requiring constant checks for >the hardware being gone), which I deemed to be an acceptable >cost/benefit. When I pop a card out, it should _never_ crash. If there's no way to avoid the chance of a crash (even 1%), you should not support popping of (active) cards out at all. Of course, it depends on what problem we're talking about here - if the consequence is much less severe than crashing, then that's different, and minimizing the chance of it may be reasonable. >Now, you may consider it acceptable, and the costs may be better/worse >than what I predicted, so feel free to hack away on the code and see >what falls out. IMO the costs far outweigh the benefits... Perhaps you should fill us in on the costs and benefits, and we may all come to agree with you once we know the issues. It doesn't hurt to hash it out in public, which also (I assume) gets captured for the record. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com CDA II has been passed and signed, sigh. The lawsuit has been filed. Please support the organizations fighting it - ACLU, EFF, CDT, etc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 26 8:28:28 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9EDBA14D12 for ; Tue, 26 Oct 1999 08:28:24 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA21536 for ; Tue, 26 Oct 1999 17:28:23 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA21176 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 17:28:23 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 0D43514D12 for ; Tue, 26 Oct 1999 08:25:17 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id JAA15393; Tue, 26 Oct 1999 09:25:04 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA18872; Tue, 26 Oct 1999 09:25:03 -0600 Date: Tue, 26 Oct 1999 09:25:03 -0600 Message-Id: <199910261525.JAA18872@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Randell Jesup Cc: nate@mt.sri.com (Nate Williams), Terry Lambert , imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> I think that a driver that crashes the system as a result of > >> the hardware being ejected is arguably a broken driver, from > >> the standpoint of complying with the Windows removable device > >> driver writers guide. > > > >Not true. The design simply does not take into account the fact that > >certain hardware/software interactions can not be coded in such a way to > >always recognize that the hardware is gone. > > > >The PCMCIA/PCCARD hardware/software specification did not take into > >account some very important design considerations. > > Such as? Of course, just because the MS spec says you should be > able to pop out the hardware at any time doesn't mean you can't make > software that says "you MUST shut down the driver before removing the card > or you may lose all your work", but the problem with that is that it breaks > the user's expectations, especially if all the other vendors handle it. > Not to mention that it's a bad idea from a CHI standpoint. You're missing the point. What happens if I'm in the middle of a ISR when the device is popped out? How do I recognize that it's gone, when I'm expecting the hardware to respond to some request I've sent it? What happens when I'm reading a piece of memory that no longer exists? > >It's broken by design, and although I can minimize the problems in > >software, there are still going to be races inherent in the design. > > Then change the design. I can't. I don't control the hardware such that the software can be informed that the device is being removed *before* the hardware is removed. > >The mostly working suspend/resume code in FreeBSD is *my* attempt to > >minimize those races, but stating that those races don't exist is > >foolish. I worked hard (and got lost of good help from Bruce) to > >make the window small, but in the end realized that it it couldn't be > >fully eliminated, and to minimize it further required re-writing many of > >the existing drivers, which would potentialy reduce performance and > >increase complexity with very little 'gain'. > > Why can't it be fully eliminated? See above, plus previous emails sent on the topic. If that isn't enough, go read the specification and go think about the problem a little bit. And if this sounds harsh, it's not meant to, but trying to explain why it's a problem requires a little bit of experience trying to fix the problem plus some out of the box thinking about the problem. [ And yes, I've thought about the problem, plus I've coded up the existing suspend/resume code in FreeBSD to minimize the race, but I've not eliminated it since I believe it can't be eliminated completely. ] > When I pop a card out, it should _never_ crash. If there's no > way to avoid the chance of a crash (even 1%), you should not support > popping of (active) cards out at all. That's my point. You can claim to not support it (like Win98 does), but it doesn't stop people from doing it. If they do it it'll crash, so who looks bad, the OS or the person? Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 26 10: 5:32 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C82A814D62 for ; Tue, 26 Oct 1999 10:05:05 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA22676 for ; Tue, 26 Oct 1999 19:04:56 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA21665 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 19:04:55 +0200 (MET DST) Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 8616C14BF9 for ; Tue, 26 Oct 1999 10:04:40 -0700 (PDT) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id A838B1C2B; Tue, 26 Oct 1999 12:07:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 9A4203817; Tue, 26 Oct 1999 12:07:08 -0400 (EDT) Date: Tue, 26 Oct 1999 12:07:08 -0400 (EDT) From: Bill Fumerola To: Nate Williams Cc: Terry Lambert , imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910260105.TAA16714@mt.sri.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 Mon, 25 Oct 1999, Nate Williams wrote: > > The system will not crash as a result of this. > > Not true, it will hang the system. I can show this if more proof is > needed on my laptop. There is no software solution that will avoid all > problems. Then you have borked drivers or some other bogon. I can cleanly do all of the things Terry says without problem. This alone means it is not only possible, but there exists a method to do it properly. I'm trying not to add noise because I have no idea of the technical workings behind pccard ejection, but lets certainly not discount it just because on someone's laptop it doesn't work. Going on that theory, I have a non-working RealPort card in my laptop... -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 26 10:34: 0 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E117A14F43 for ; Tue, 26 Oct 1999 10:33:43 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA22896 for ; Tue, 26 Oct 1999 19:33:40 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA21763 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 19:33:40 +0200 (MET DST) Received: from green.myip.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B8F5114D4E; Tue, 26 Oct 1999 10:33:12 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost ([127.0.0.1] ident=green) by green.myip.org with esmtp (Exim 3.02 #1) id 11gAT2-000GhY-00; Tue, 26 Oct 1999 13:33:04 -0400 Date: Tue, 26 Oct 1999 13:33:02 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.myip.org To: Kris Kennaway Cc: Pascal Hofstee , freebsd-hackers@freebsd.org, arch@freebsd.org Subject: Re: module names 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 I, for one, like what was suggested a long time ago, by someone who I cannot really remember. It separated driver "classes" in /modules subdirectories. For instance, we could have a "net" for the if_foo drivers, "storage" for CAM/ATA/RAID/Vinum/CCD/etc., "periph" for various esoteric peripherals, "exec" for exec formats like svr4/linux/ ibcs2, "video" for vesa/*_saver, "fs" for filesystems (separate from storage), and "netsub" for ipfw/streams/loadable socket domains. I think that, perhaps, there should be a "bus" where pccard, usb, and SCSI cards would go (instead of "storage"). Currently, we don't have way too many modules, so I'm happy with what's here now. I definitely think there's room for improvement in how /modules is organized, but remember that the format came straight from what we used to have in /lkm. -- 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 Tue Oct 26 11:30:41 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9487F14C32 for ; Tue, 26 Oct 1999 11:30:38 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA23490 for ; Tue, 26 Oct 1999 20:30:27 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA22052 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 20:30:25 +0200 (MET DST) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 3214B14D58 for ; Tue, 26 Oct 1999 11:29:40 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (ind.alcatel.com 2.3 [OUT])) id LAA21253; Tue, 26 Oct 1999 11:27:55 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id LAA10433; Tue, 26 Oct 1999 11:27:55 -0700 Received: from softweyr.com (dyn7.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA29107; Tue, 26 Oct 99 11:27:37 PDT Message-Id: <3815F2A0.FA3442F4@softweyr.com> Date: Tue, 26 Oct 1999 12:27:44 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Randell Jesup Cc: Nate Williams , Terry Lambert , imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Randell Jesup wrote: > > Nate Williams writes: > > >Not true. The design simply does not take into account the fact that > >certain hardware/software interactions can not be coded in such a way to > >always recognize that the hardware is gone. > > > >The PCMCIA/PCCARD hardware/software specification did not take into > >account some very important design considerations. > > Such as? Of course, just because the MS spec says you should be > able to pop out the hardware at any time doesn't mean you can't make > software that says "you MUST shut down the driver before removing the card > or you may lose all your work", but the problem with that is that it breaks > the user's expectations, especially if all the other vendors handle it. > Not to mention that it's a bad idea from a CHI standpoint. The PCMCIA spec had nothing to do with Microsoft, and wasn't designed for things like modems, network cards, and disk drives. In case you've forgotten, or never knew, it was a Personal Computer MEMORY CARD specification, and it was not expected that changes would be queued to the devices, but rather written directly. This is a HARDWARE spec, originally developed by Data I/O and later munged by a cast of thousands. It is arguable that any I/O performed to a PCMCIA device should be done entirely synchronously so that the operation can succeed or fail without the possibility of the card being removed AFTER the operation has been queued but before it completes. This would, of course, blow any chance of reasonable performance. > >It's broken by design, and although I can minimize the problems in > >software, there are still going to be races inherent in the design. > > Then change the design. That's a good answer. Let's get all of the hardware vendors to scrap what they've done and create a working ejectable card design that will cost several times as much. That's real likely to happen. This is one of those things where you pay your money and take your prize, even if it's not much of a prize at all. > >It works 98% of the time now, and to make it work 99% of the time > >required a lot of work for only 1% gain. That 1% of gain in 'stability' > >may cost 10-15% in terms of performance (requiring constant checks for > >the hardware being gone), which I deemed to be an acceptable > >cost/benefit. > > When I pop a card out, it should _never_ crash. If there's no > way to avoid the chance of a crash (even 1%), you should not support > popping of (active) cards out at all. We can't do that, because the hardware has no capability to lock the card into the machine. If you just tell everyone "don't pop your PCCards out or your system will crash" they'll just accuse you of being incompetent and move on to a system that does it correctly 95% or 98% of the time. > Of course, it depends on what > problem we're talking about here - if the consequence is much less > severe than crashing, then that's different, and minimizing the chance > of it may be reasonable. You're talking more about a tradeoff in boundary conditions. Would you rather have it do something nefarious during 1% of card ejections but otherwise work quite well, or have it never do anything stupid at all but deliver such abysmal performance it is unusable even for those who never eject cards while the system is running? > > Now, you may consider it acceptable, and the costs may be better/worse > > than what I predicted, so feel free to hack away on the code and see > > what falls out. IMO the costs far outweigh the benefits... > > Perhaps you should fill us in on the costs and benefits, and > we may all come to agree with you once we know the issues. It doesn't > hurt to hash it out in public, which also (I assume) gets captured for > the record. Ah, discussing the issues involved is quite a reasonable thing to do. Assuming those who have gone before you are idiots who just don't under- stand how to code correctly is probably not. Perhaps you just didn't phrase your question well? I'm certainly willing to give you chapter and verse on what a poor idea the PCMCIA ejection notification is, and some of the other weaknesses in the spec, but having a copy of the spec or the "PCMCIA System Architecture" book (ISBN: 0201409917) handy will help. -- "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 Tue Oct 26 12:55:57 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C724014FA4 for ; Tue, 26 Oct 1999 12:54:03 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA24278 for ; Tue, 26 Oct 1999 21:54:00 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA22427 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 21:53:58 +0200 (MET DST) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id E4DE314F79 for ; Tue, 26 Oct 1999 12:42:22 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id PAA08574; Tue, 26 Oct 1999 15:36:57 -0400 (EDT) Reply-To: Randell Jesup To: nate@mt.sri.com (Nate Williams) Cc: Terry Lambert , imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <199910261525.JAA18872@mt.sri.com> From: Randell Jesup Date: 26 Oct 1999 15:38:20 +0000 In-Reply-To: Nate Williams's message of "Tue, 26 Oct 1999 09:25:03 -0600" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams writes: >> >The PCMCIA/PCCARD hardware/software specification did not take into >> >account some very important design considerations. >> >> Such as? Of course, just because the MS spec says you should be >> able to pop out the hardware at any time doesn't mean you can't make >> software that says "you MUST shut down the driver before removing the card >> or you may lose all your work", but the problem with that is that it breaks >> the user's expectations, especially if all the other vendors handle it. >> Not to mention that it's a bad idea from a CHI standpoint. > >You're missing the point. What happens if I'm in the middle of a ISR >when the device is popped out? How do I recognize that it's gone, when >I'm expecting the hardware to respond to some request I've sent it? >What happens when I'm reading a piece of memory that no longer exists? Ok, talking to the technical issues: [This assumes there's a high-priority interrupt to notify us of card removal, and the ISR for the interrupt merely sets a flag. It also assumes that the hardware doesn't go away before the interrupt occurs, but may be gone by the time the processor handles the interrupt, and that all pccard ISR's are at a lower interrupt priority than the hardware-is- gone int.] First, if you're reading memory that may not exist, check a flag (whatever) after a series of associated reads, and use that to know if the reads may have been garbage or not. After sending a request to the hardware (probably by writing to a register), check said flag, and if the hardware is gone, abort the transaction (to the caller) with an error. When a card is removed, wake up all pccard drivers that are in sleeps waiting on hardware, and let them notice that the hardware is gone and appropriately error out requests. If you're in the middle of an ISR: Check said flag (insertion state) at appropriate points. In many cases, you merely need check once or twice I suspect. (I assume writes to removed cards go into the ether, and reads return something random, which you may need to watch out for - but often only one check before commiting the results of the interrupt.) Even if you have to check it a fair number of times, the overhead shouldn't be large. Have I missed something? Some aspect of Unix device drivers I'm not familiar with? >> >It's broken by design, and although I can minimize the problems in >> >software, there are still going to be races inherent in the design. >> >> Then change the design. > >I can't. I don't control the hardware such that the software can be >informed that the device is being removed *before* the hardware is >removed. Sorry, I should have been more specific (or the person I replied to (you?) should have been): I meant the software/driver design. >> >foolish. I worked hard (and got lost of good help from Bruce) to >> >make the window small, but in the end realized that it it couldn't be >> >fully eliminated, and to minimize it further required re-writing many of >> >the existing drivers, which would potentialy reduce performance and >> >increase complexity with very little 'gain'. >> >> Why can't it be fully eliminated? > >See above, plus previous emails sent on the topic. If that isn't >enough, go read the specification and go think about the problem a >little bit. And if this sounds harsh, it's not meant to, but trying to >explain why it's a problem requires a little bit of experience trying to >fix the problem plus some out of the box thinking about the problem. > >[ >And yes, I've thought about the problem, plus I've coded up the >existing suspend/resume code in FreeBSD to minimize the race, but I've >not eliminated it since I believe it can't be eliminated completely. >] Understood - note that I have programmed PCMCIA devices in the (fairly far) past, along with many other hardware drivers, though not under Unix. >> When I pop a card out, it should _never_ crash. If there's no >> way to avoid the chance of a crash (even 1%), you should not support >> popping of (active) cards out at all. > >That's my point. You can claim to not support it (like Win98 does), but >it doesn't stop people from doing it. If they do it it'll crash, so who >looks bad, the OS or the person? The OS/drivers, whether or not it's justified. There are ways to browbeat users into not doing it, however. (Such as by screaming bloody murder if they do, even when it doesn't crash.) -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com CDA II has been passed and signed, sigh. The lawsuit has been filed. Please support the organizations fighting it - ACLU, EFF, CDT, etc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 26 13: 9:56 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1668E14C07 for ; Tue, 26 Oct 1999 13:09:33 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA24436 for ; Tue, 26 Oct 1999 22:09:27 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA22503 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 22:09:27 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 5269914CF5 for ; Tue, 26 Oct 1999 13:08:17 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id OAA17887; Tue, 26 Oct 1999 14:07:40 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA20106; Tue, 26 Oct 1999 14:07:38 -0600 Date: Tue, 26 Oct 1999 14:07:38 -0600 Message-Id: <199910262007.OAA20106@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Randell Jesup Cc: nate@mt.sri.com (Nate Williams), Terry Lambert , imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <199910261525.JAA18872@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >You're missing the point. What happens if I'm in the middle of a ISR > >when the device is popped out? How do I recognize that it's gone, when > >I'm expecting the hardware to respond to some request I've sent it? > >What happens when I'm reading a piece of memory that no longer exists? > > Ok, talking to the technical issues: > > [This assumes there's a high-priority interrupt to notify us of > card removal, and the ISR for the interrupt merely sets a flag. Note, many ISR are *NOT* interruptable (fast interrupts for one), or may be in the middle of some critical section where *all* interrupts are disabled, so notification is never given. > It also > assumes that the hardware doesn't go away before the interrupt occurs, > but may be gone by the time the processor handles the interrupt, and that > all pccard ISR's are at a lower interrupt priority than the hardware-is- > gone int.] See above. The existing FreeBSD code is coded as above (by not allowing fast interrupts on serial cards, causing performance to suck badly), but still there are problems. One, we can't use fast interrupts. Two, the drivers can still be in a critical section when the hardware is removed, and there's nothing you can do. This is the 1% case that there's nothing we can do about. (In reality, it may be .1% or even .001%, but I'll bet is closer to 1% than the rest, and it depends on the particular device driver in question.) > First, if you're reading memory that may not exist, check a > flag (whatever) after a series of associated reads, and use that to > know if the reads may have been garbage or not. No we're in the other 1% case that we can work around bug. In this 1% case, in order to do all these checks, we're effectively killing performance (10-15%) because these checks happen in the portion of the code that directly effects how effecient the driver is. > Have I missed something? Some aspect of Unix device drivers I'm > not familiar with? Nope, but this as already mentioned in the disucssion previously, and my statement was that the cost (10-15% performance hit) wasn't worth the benefit. The cost may be less, and the benefit may be greater, but since I was the one doing the coding, I deemed it an unacceptable tradeoff. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 26 13:11:47 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E39ED14CAE for ; Tue, 26 Oct 1999 13:11:33 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA24462 for ; Tue, 26 Oct 1999 22:11:31 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA22536 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 22:11:30 +0200 (MET DST) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id BC91A14CAE for ; Tue, 26 Oct 1999 13:09:29 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (ind.alcatel.com 2.3 [OUT])) id NAA23271; Tue, 26 Oct 1999 13:08:33 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id NAA15793; Tue, 26 Oct 1999 13:08:33 -0700 Received: from softweyr.com (dyn7.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA04732; Tue, 26 Oct 99 13:08:22 PDT Message-Id: <38160A3D.F32AE9E4@softweyr.com> Date: Tue, 26 Oct 1999 14:08:29 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Bill Fumerola Cc: Nate Williams , Terry Lambert , imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Fumerola wrote: > > On Mon, 25 Oct 1999, Nate Williams wrote: > > > > The system will not crash as a result of this. > > > > Not true, it will hang the system. I can show this if more proof is > > needed on my laptop. There is no software solution that will avoid all > > problems. > > Then you have borked drivers or some other bogon. I can cleanly do all > of the things Terry says without problem. This alone means it is not only > possible, but there exists a method to do it properly. Try this: hang a disk drive off a SlimSCSI and start something I/O intensive on the drive, like a disk benchmark write test. Now pop the SCSI card out during the I/O. > I'm trying not to add noise because I have no idea of the technical workings > behind pccard ejection, but lets certainly not discount it just because > on someone's laptop it doesn't work. First you should know PCMCIA was designed with memory cards in mind. The ejection mechanism tells you the card is going away by providing an interrupt. It's the same interrupt that all other notifications from the card use. It does this by having a short pin on the connector; when the short pin becomes detached the PCMCIA Controller in your system generates the interrupt. You have some small amount of time before the rest of the pins become detached in which you can still communicate with the card, but this time is not fixed, it will depend on the card, the ejector, and on how hard the user pushes the ejector button. If you've just begun to process another interrupt from the card, such as I/O ready or I/O complete, you won't be able to process the ejection interrupt until your current interrupt completes, but what happens if the card goes away before your current interrupt completes? Then you're attempting to read and write I/O ports and/or memory locations that no longer exist, but you don't know they no longer exist. The "right" thing to do would be for the hardware controller to generate a bus error if you try to write registers or memory addresses for a card that has gone away, but it doesn't. You're also left with questions about what to do with outstanding I/O requests when the device goes away, and how to handle the open references to the device. None of the design is simple, and it is complicated by the fact that PCMCIA wasn't developed for I/O devices. If you want to jump in and help, I'm sure everyone involved would welcome the help. Buy the PCMCIA and CardBus architecture books, familiarize yourself with the code, and ponder how to handle these and other stick issues as cleanly as possible. Submit working patches, ask intelligent questions, and give intelligent answers. You know, kind of like working on FreeBSD. ;^) -- "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 Tue Oct 26 18:41:21 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0322214C2D for ; Tue, 26 Oct 1999 18:41:14 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA29072 for ; Wed, 27 Oct 1999 03:41:12 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA23716 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 03:41:11 +0200 (MET DST) Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id A676914C2D for ; Tue, 26 Oct 1999 18:40:59 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.1/8.9.1) id SAA70828; Tue, 26 Oct 1999 18:40:55 -0700 Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp05.primenet.com, id smtpdS8IMMa; Tue Oct 26 18:40:49 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id SAA16700; Tue, 26 Oct 1999 18:40:46 -0700 (MST) From: Terry Lambert Message-Id: <199910270140.SAA16700@usr02.primenet.com> Subject: Re: Racing interrupts To: nate@mt.sri.com Date: Wed, 27 Oct 1999 01:40:45 +0000 (GMT) Cc: rjesup@wgate.com, tlambert@primenet.com, imp@village.org, arch@freebsd.org In-Reply-To: <199910261525.JAA18872@mt.sri.com> from "Nate Williams" at Oct 26, 99 09:25:03 am X-Mailer: ELM [version 2.4 PL25] 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 > > Such as? Of course, just because the MS spec says you should be > > able to pop out the hardware at any time doesn't mean you can't make > > software that says "you MUST shut down the driver before removing the card > > or you may lose all your work", but the problem with that is that it breaks > > the user's expectations, especially if all the other vendors handle it. > > Not to mention that it's a bad idea from a CHI standpoint. > > You're missing the point. What happens if I'm in the middle of a ISR > when the device is popped out? You get a higher priority device eject interrupt, and abort the device ISR before exiting the higher priority interrupt routine. > How do I recognize that it's gone, when I'm expecting the hardware > to respond to some request I've sent it? You get the eject interrupt. > What happens when I'm reading a piece of memory that no longer exists? You don't keep reading, once you get the eject interrupt, because you don't ever return to the code that was doing the reading. For any mmap()'ed device memory (why are you allowing this?) you fault the process. You do not allow memory mapped I/O to a device except in a real or soft ISR with a lower priority than the eject ISR. > > Why can't it be fully eliminated? > > See above, plus previous emails sent on the topic. If that isn't > enough, go read the specification and go think about the problem a > little bit. And if this sounds harsh, it's not meant to, but trying to > explain why it's a problem requires a little bit of experience trying to > fix the problem plus some out of the box thinking about the problem. > > [ > And yes, I've thought about the problem, plus I've coded up the > existing suspend/resume code in FreeBSD to minimize the race, but I've > not eliminated it since I believe it can't be eliminated completely. > ] On a CardBus system, according to the MindShare book, the only really tricky part is that there is a single interrupt that's used. This means that you need to make your interrupt handler reentrant, which is difficult, but not impossible. The way you deal with this is an "enabler". Another alternative, suggested by the book, is to explicitly except faults in protected mode that deal with the cardbus space, and to handle them specially in the fault handler. In the Plug and Play System Architecture, according to that MindShare book, notification from the bridge chip is required to the configuration manager. This is accomplished via an enabler (the enabler in UnixWare, written by Kurt Mahon in 1994, is called "enpic"). The point is that, while I agree it's a lot of work, the problem _is_ resolvable, and that's what FreeBSD should really be striving to achieve. Except with explicitly non-conformant drivers, this problem has been solved on Windows 98 and 2000. > > When I pop a card out, it should _never_ crash. If there's no > > way to avoid the chance of a crash (even 1%), you should not support > > popping of (active) cards out at all. > > That's my point. You can claim to not support it (like Win98 does), but > it doesn't stop people from doing it. If they do it it'll crash, so who > looks bad, the OS or the person? I think he meant support that particular card, with the brain damaged driver that allows it to crash. 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 Oct 26 18:49:10 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 334E814D6F for ; Tue, 26 Oct 1999 18:49:02 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA29154 for ; Wed, 27 Oct 1999 03:49:01 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA23771 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 03:49:01 +0200 (MET DST) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 3BB2814C2D for ; Tue, 26 Oct 1999 18:48:49 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id SAA17519; Tue, 26 Oct 1999 18:48:34 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpdAAAGYaWhI; Tue Oct 26 18:48:30 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id SAA17060; Tue, 26 Oct 1999 18:48:23 -0700 (MST) From: Terry Lambert Message-Id: <199910270148.SAA17060@usr02.primenet.com> Subject: Re: Racing interrupts To: rjesup@wgate.com Date: Wed, 27 Oct 1999 01:48:23 +0000 (GMT) Cc: nate@mt.sri.com, tlambert@primenet.com, imp@village.org, arch@freebsd.org In-Reply-To: from "Randell Jesup" at Oct 26, 99 03:38:20 pm X-Mailer: ELM [version 2.4 PL25] 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, talking to the technical issues: > > [This assumes there's a high-priority interrupt to notify us of > card removal, and the ISR for the interrupt merely sets a flag. It also > assumes that the hardware doesn't go away before the interrupt occurs, > but may be gone by the time the processor handles the interrupt, and that > all pccard ISR's are at a lower interrupt priority than the hardware-is- > gone int.] Invalid assumption, but fixable via virtualization to be virtually true (this is handleable via a reentrancy counter). > First, if you're reading memory that may not exist, check a > flag (whatever) after a series of associated reads, and use that to > know if the reads may have been garbage or not. Yes. > After sending a request to the hardware (probably by writing to > a register), check said flag, and if the hardware is gone, abort the > transaction (to the caller) with an error. Yes. > When a card is removed, wake up all pccard drivers that are in > sleeps waiting on hardware, and let them notice that the hardware is > gone and appropriately error out requests. Yes. > If you're in the middle of an ISR: Check said flag (insertion > state) at appropriate points. In many cases, you merely need check once > or twice I suspect. (I assume writes to removed cards go into the ether, > and reads return something random, which you may need to watch out for - > but often only one check before commiting the results of the interrupt.) > Even if you have to check it a fair number of times, the overhead shouldn't > be large. > > Have I missed something? Some aspect of Unix device drivers I'm > not familiar with? Nate's point about putting the checks into each driver, in particular given that these drivers are shared with less ...transigent hardware, is valid. This is adressibly on the was into the ISR by checking a bit to see if this is a hot swappable device, and eating stack state save overhead, though. The overhead doesn't occur except for the devices where it's necessary to avoid crashes. I'd like to get agreed that it's possible to work around the crappy hardware, to get a roadmap laid down, even if there isn't currently code. 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 Oct 26 19: 2:39 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B48BF14FC5 for ; Tue, 26 Oct 1999 19:02:31 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA29295 for ; Wed, 27 Oct 1999 04:02:30 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA23841 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 04:02:30 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 0207A14FC5 for ; Tue, 26 Oct 1999 19:02:21 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id UAA20950; Tue, 26 Oct 1999 20:02:16 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id UAA21309; Tue, 26 Oct 1999 20:02:14 -0600 Date: Tue, 26 Oct 1999 20:02:14 -0600 Message-Id: <199910270202.UAA21309@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com, rjesup@wgate.com, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910270140.SAA16700@usr02.primenet.com> References: <199910261525.JAA18872@mt.sri.com> <199910270140.SAA16700@usr02.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Such as? Of course, just because the MS spec says you should be > > > able to pop out the hardware at any time doesn't mean you can't make > > > software that says "you MUST shut down the driver before removing the card > > > or you may lose all your work", but the problem with that is that it breaks > > > the user's expectations, especially if all the other vendors handle it. > > > Not to mention that it's a bad idea from a CHI standpoint. > > > > You're missing the point. What happens if I'm in the middle of a ISR > > when the device is popped out? > > > You get a higher priority device eject interrupt, and abort the device > ISR before exiting the higher priority interrupt routine. You simply don't get it, no matter how many times I've said it. I refuse to repeat myself over and over simply because you are unable to read what I've wrote. Most of your arguments are based on faulty assumptions, which have been pointed out over and over. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 26 19: 4:44 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6F66414FC5 for ; Tue, 26 Oct 1999 19:04:36 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA29313 for ; Wed, 27 Oct 1999 04:04:35 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA23868 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 04:04:35 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 0A5A214FC5 for ; Tue, 26 Oct 1999 19:04:27 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id UAA20973; Tue, 26 Oct 1999 20:04:21 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id UAA21334; Tue, 26 Oct 1999 20:04:20 -0600 Date: Tue, 26 Oct 1999 20:04:20 -0600 Message-Id: <199910270204.UAA21334@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: rjesup@wgate.com, nate@mt.sri.com, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910270148.SAA17060@usr02.primenet.com> References: <199910270148.SAA17060@usr02.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'd like to get agreed that it's possible to work around the crappy > hardware, to get a roadmap laid down, even if there isn't currently > code. Much of *code* that you are are screaming for *EXISTS* in FreeBSD today, and guess what, it doesn't work very well, because of all the problems I've pointed out. I wrote the code, so there's no need for roadmaps and/or long discussions about the merits of it. The basic problem that Warner was discussing is a 'fact of life', and fixing it to never occur is simply not possible, and making it better than it already is implies a huge overhead. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 26 19:57:56 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BCE2314D1F for ; Tue, 26 Oct 1999 19:57:54 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA29646 for ; Wed, 27 Oct 1999 04:57:52 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA24041 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 04:57:51 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id F0BCF14ED2 for ; Tue, 26 Oct 1999 19:57:44 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA37546; Tue, 26 Oct 1999 20:57:43 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA58991; Tue, 26 Oct 1999 20:58:45 -0600 (MDT) Message-Id: <199910270258.UAA58991@harmony.village.org> To: nate@mt.sri.com (Nate Williams) Subject: Re: Racing interrupts Cc: Terry Lambert , rjesup@wgate.com, arch@freebsd.org In-reply-to: Your message of "Tue, 26 Oct 1999 20:04:20 MDT." <199910270204.UAA21334@mt.sri.com> References: <199910270204.UAA21334@mt.sri.com> <199910270148.SAA17060@usr02.primenet.com> Date: Tue, 26 Oct 1999 20:58:45 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199910270204.UAA21334@mt.sri.com> Nate Williams writes: : Much of *code* that you are are screaming for *EXISTS* in FreeBSD today, : and guess what, it doesn't work very well, because of all the problems : I've pointed out. It works much worse sense I broke it as well in the past few days, so if you go looking at a really -current laptop and suspend/card eject doesn't work you can blame me for screwing it up, and not Nate. His code works about as well as can be expected given the nature of pccard as well as the existing FreeBSD drivers... I may need to do something similar to the newconfig stuff when it gets into the kind of shape where card eject becomes an issue :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 1: 5:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 67B9D152C4 for ; Wed, 27 Oct 1999 01:05:31 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA02802 for ; Wed, 27 Oct 1999 10:05:29 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA24983 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 10:05:28 +0200 (MET DST) Received: from habanero.netmonger.net (host2.elkay.on.yiff.net [209.54.22.163]) by hub.freebsd.org (Postfix) with ESMTP id 0130015321 for ; Wed, 27 Oct 1999 01:05:11 -0700 (PDT) (envelope-from chris@habanero.netmonger.net) Received: (from chris@localhost) by habanero.netmonger.net (8.9.3/8.9.3) id EAA00606 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 04:05:10 -0400 (EDT) (envelope-from chris) Date: Wed, 27 Oct 1999 04:05:10 -0400 From: Christopher Masto To: freebsd-arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <19991027040510.A534@netmonger.net> References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <3815F2A0.FA3442F4@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <3815F2A0.FA3442F4@softweyr.com>; from Wes Peters on Tue, Oct 26, 1999 at 12:27:44PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Given where we are right now in -current, would it be sensible to consider finding a way to disable devices before ejecting them? I'm plenty willing to have to "shut down" a card before removing it, but having no way to do so at the moment, I will shortly be fully shutting down the laptop I'm writing this on just so I can put it away. To put it another way.. whether the problem is impossible to solve or just very very hard to solve, if a solution is not imminent, it may be time to at least find a workaround. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 1:12:21 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BB68C152C4 for ; Wed, 27 Oct 1999 01:12:18 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA02939 for ; Wed, 27 Oct 1999 10:12:17 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA25034 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 10:12:17 +0200 (MET DST) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 44B16152C4 for ; Wed, 27 Oct 1999 01:12:08 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id RAA10445; Wed, 27 Oct 1999 17:41:58 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19991027040510.A534@netmonger.net> Date: Wed, 27 Oct 1999 17:41:58 +0930 (CST) From: "Daniel O'Connor" To: Christopher Masto Subject: Re: Racing interrupts Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27-Oct-99 Christopher Masto wrote: > To put it another way.. whether the problem is impossible to solve or > just very very hard to solve, if a solution is not imminent, it may > be time to at least find a workaround. Doesn't powering down the card work? Or does that pull the rug too? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 9:27: 3 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 54BDD15027 for ; Wed, 27 Oct 1999 09:26:59 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA11797 for ; Wed, 27 Oct 1999 18:26:58 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA27425 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 18:26:58 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 3533715027 for ; Wed, 27 Oct 1999 09:26:27 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id KAA40213; Wed, 27 Oct 1999 10:26:25 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA64604; Wed, 27 Oct 1999 10:27:34 -0600 (MDT) Message-Id: <199910271627.KAA64604@harmony.village.org> To: "Daniel O'Connor" Subject: Re: Racing interrupts Cc: Christopher Masto , freebsd-arch@freebsd.org In-reply-to: Your message of "Wed, 27 Oct 1999 17:41:58 +0930." References: Date: Wed, 27 Oct 1999 10:27:34 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Daniel O'Connor" writes: : Doesn't powering down the card work? : Or does that pull the rug too? It depends. You need to detach the driver from the system, and then you can safely remove power from the card. This usually will generate an unfielded interrupt (since the card will have detached its ISR from the vector), but that's usually the worst of it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 10: 4:48 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 99BF015055 for ; Wed, 27 Oct 1999 10:04:32 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA12195 for ; Wed, 27 Oct 1999 19:04:30 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA27720 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 19:04:30 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 9148E14C9B for ; Wed, 27 Oct 1999 10:03:41 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA28118; Wed, 27 Oct 1999 11:03:40 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA24447; Wed, 27 Oct 1999 11:03:39 -0600 Date: Wed, 27 Oct 1999 11:03:39 -0600 Message-Id: <199910271703.LAA24447@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Christopher Masto Cc: freebsd-arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <19991027040510.A534@netmonger.net> References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <3815F2A0.FA3442F4@softweyr.com> <19991027040510.A534@netmonger.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Given where we are right now in -current, would it be sensible to > consider finding a way to disable devices before ejecting them? I'm > plenty willing to have to "shut down" a card before removing it, but > having no way to do so at the moment, I will shortly be fully shutting > down the laptop I'm writing this on just so I can put it away. > > To put it another way.. whether the problem is impossible to solve or > just very very hard to solve, if a solution is not imminent, it may > be time to at least find a workaround. In PAO, there is some ability to power-down a card, which is a good thing. The amount of code required to add that functionality is not too difficult, but I think Warner's got enough on his plate for now. However, I'll bet if someone took out the 'relevant bits' out of the PAO release and submitted them, they might find their way into stock FreeBSD. ;) (Note the words 'relevant bits'.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 10:11:26 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5655314EAC for ; Wed, 27 Oct 1999 10:11:17 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA12294 for ; Wed, 27 Oct 1999 19:11:13 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA27790 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 19:11:13 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id E274514EAC for ; Wed, 27 Oct 1999 10:11:03 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA40532; Wed, 27 Oct 1999 11:11:02 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id LAA65029; Wed, 27 Oct 1999 11:12:12 -0600 (MDT) Message-Id: <199910271712.LAA65029@harmony.village.org> To: nate@mt.sri.com (Nate Williams) Subject: Re: Racing interrupts Cc: Christopher Masto , freebsd-arch@freebsd.org In-reply-to: Your message of "Wed, 27 Oct 1999 11:03:39 MDT." <199910271703.LAA24447@mt.sri.com> References: <199910271703.LAA24447@mt.sri.com> <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <3815F2A0.FA3442F4@softweyr.com> <19991027040510.A534@netmonger.net> Date: Wed, 27 Oct 1999 11:12:12 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199910271703.LAA24447@mt.sri.com> Nate Williams writes: : In PAO, there is some ability to power-down a card, which is a good : thing. The amount of code required to add that functionality is not too : difficult, but I think Warner's got enough on his plate for now. : : However, I'll bet if someone took out the 'relevant bits' out of the PAO : release and submitted them, they might find their way into stock : FreeBSD. ;) There was a post to -mobile that had what appeared to be the relevant bits that I'm keeping in my inbox. Won't apply to recent -current, but will apply to -stable. I'm not sure how to handle (and hadn't even though of until just now) the pccardc functionality... I'll worry about tht when it becomes an issue. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 10:17:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A912714E01 for ; Wed, 27 Oct 1999 10:17:47 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA12386 for ; Wed, 27 Oct 1999 19:17:44 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA27860 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 19:17:44 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 1C9BE14E01 for ; Wed, 27 Oct 1999 10:17:35 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA28254; Wed, 27 Oct 1999 11:17:32 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA24571; Wed, 27 Oct 1999 11:17:30 -0600 Date: Wed, 27 Oct 1999 11:17:30 -0600 Message-Id: <199910271717.LAA24571@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: nate@mt.sri.com (Nate Williams), Christopher Masto , freebsd-arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910271712.LAA65029@harmony.village.org> References: <199910271703.LAA24447@mt.sri.com> <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <3815F2A0.FA3442F4@softweyr.com> <19991027040510.A534@netmonger.net> <199910271712.LAA65029@harmony.village.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : In PAO, there is some ability to power-down a card, which is a good > : thing. The amount of code required to add that functionality is not too > : difficult, but I think Warner's got enough on his plate for now. > : > : However, I'll bet if someone took out the 'relevant bits' out of the PAO > : release and submitted them, they might find their way into stock > : FreeBSD. ;) > > There was a post to -mobile that had what appeared to be the relevant > bits that I'm keeping in my inbox. Won't apply to recent -current, > but will apply to -stable. Cool. > I'm not sure how to handle (and hadn't even though of until just now) > the pccardc functionality... I'll worry about tht when it becomes an > issue. I'm not sure I follow. You mean adding the bits to support the new 'power' ioctl, or something else? What issues are you aware of? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 10:18:57 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0778714E01 for ; Wed, 27 Oct 1999 10:18:54 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA12413 for ; Wed, 27 Oct 1999 19:18:53 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA27895 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 19:18:52 +0200 (MET DST) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 028F514FF6 for ; Wed, 27 Oct 1999 10:18:40 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (ind.alcatel.com 2.3 [OUT])) id KAA08974; Wed, 27 Oct 1999 10:17:24 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id KAA01634; Wed, 27 Oct 1999 10:17:25 -0700 Received: from softweyr.com (dyn7.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA04938; Wed, 27 Oct 99 10:17:14 PDT Message-Id: <381733A1.B14908D2@softweyr.com> Date: Wed, 27 Oct 1999 11:17:21 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Terry Lambert Cc: nate@mt.sri.com, rjesup@wgate.com, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts References: <199910270140.SAA16700@usr02.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > The point is that, while I agree it's a lot of work, the problem > _is_ resolvable, and that's what FreeBSD should really be striving > to achieve. Except with explicitly non-conformant drivers, this > problem has been solved on Windows 98 and 2000. This design carries over into Compact PCI as well; something we should be looking towards for both embedded and server applications. -- "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 Wed Oct 27 10:20: 9 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1AFB114F55 for ; Wed, 27 Oct 1999 10:20:05 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA12434 for ; Wed, 27 Oct 1999 19:20:05 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA27923 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 19:20:05 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 3B0B414F55 for ; Wed, 27 Oct 1999 10:19:55 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA40616; Wed, 27 Oct 1999 11:19:54 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id LAA65186; Wed, 27 Oct 1999 11:21:04 -0600 (MDT) Message-Id: <199910271721.LAA65186@harmony.village.org> To: nate@mt.sri.com (Nate Williams) Subject: Re: Racing interrupts Cc: Christopher Masto , freebsd-arch@freebsd.org In-reply-to: Your message of "Wed, 27 Oct 1999 11:17:30 MDT." <199910271717.LAA24571@mt.sri.com> References: <199910271717.LAA24571@mt.sri.com> <199910271703.LAA24447@mt.sri.com> <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <3815F2A0.FA3442F4@softweyr.com> <19991027040510.A534@netmonger.net> <199910271712.LAA65029@harmony.village.org> Date: Wed, 27 Oct 1999 11:21:04 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199910271717.LAA24571@mt.sri.com> Nate Williams writes: : I'm not sure I follow. You mean adding the bits to support the new : 'power' ioctl, or something else? What issues are you aware of? In general, how does one query the kernel for the state of the pccard/cardbus system. I'll likely implement as much of the current /dev/card ioctl api that makes sense. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 10:34:58 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CC61D14F5B for ; Wed, 27 Oct 1999 10:34:54 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA12574 for ; Wed, 27 Oct 1999 19:34:53 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA27994 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 19:34:53 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 43BEF1543E for ; Wed, 27 Oct 1999 10:33:20 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA28420; Wed, 27 Oct 1999 11:33:15 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA24717; Wed, 27 Oct 1999 11:33:14 -0600 Date: Wed, 27 Oct 1999 11:33:14 -0600 Message-Id: <199910271733.LAA24717@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: nate@mt.sri.com (Nate Williams), Christopher Masto , freebsd-arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910271721.LAA65186@harmony.village.org> References: <199910271717.LAA24571@mt.sri.com> <199910271703.LAA24447@mt.sri.com> <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <3815F2A0.FA3442F4@softweyr.com> <19991027040510.A534@netmonger.net> <199910271712.LAA65029@harmony.village.org> <199910271721.LAA65186@harmony.village.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : I'm not sure I follow. You mean adding the bits to support the new > : 'power' ioctl, or something else? What issues are you aware of? > > In general, how does one query the kernel for the state of the > pccard/cardbus system. I'll likely implement as much of the current > /dev/card ioctl api that makes sense. pccardc/pccardd. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 10:39: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 47A7F1501A for ; Wed, 27 Oct 1999 10:39:00 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA12622 for ; Wed, 27 Oct 1999 19:38:59 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA28027 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 19:38:59 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A7E5715428 for ; Wed, 27 Oct 1999 10:38:13 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA40717; Wed, 27 Oct 1999 11:38:12 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id LAA67926; Wed, 27 Oct 1999 11:39:22 -0600 (MDT) Message-Id: <199910271739.LAA67926@harmony.village.org> To: nate@mt.sri.com (Nate Williams) Subject: Re: Racing interrupts Cc: Christopher Masto , freebsd-arch@freebsd.org In-reply-to: Your message of "Wed, 27 Oct 1999 11:33:14 MDT." <199910271733.LAA24717@mt.sri.com> References: <199910271733.LAA24717@mt.sri.com> <199910271717.LAA24571@mt.sri.com> <199910271703.LAA24447@mt.sri.com> <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <3815F2A0.FA3442F4@softweyr.com> <19991027040510.A534@netmonger.net> <199910271712.LAA65029@harmony.village.org> <199910271721.LAA65186@harmony.village.org> Date: Wed, 27 Oct 1999 11:39:22 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199910271733.LAA24717@mt.sri.com> Nate Williams writes: : > : I'm not sure I follow. You mean adding the bits to support the new : > : 'power' ioctl, or something else? What issues are you aware of? : > : > In general, how does one query the kernel for the state of the : > pccard/cardbus system. I'll likely implement as much of the current : > /dev/card ioctl api that makes sense. : : pccardc/pccardd. pccardd is going to all but go away as all the configuration of the cards is done in the kernel. Its one remianing function will be to run scripts when cards come and go. This will likely be subsumed by a devd which will do this more generically, as ell as provide a way to implement the policy of persistance for devfs. pccardc's information gathering functions make sense, but some of its other functions (setting a memory address, etc) do not and will be removed. The power functionality likely is one that can be generically applied to other devices, which would likely result in a more generic power management command in the long haul. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 10:49:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4485914FA6 for ; Wed, 27 Oct 1999 10:49:45 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA12758 for ; Wed, 27 Oct 1999 19:49:44 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA28105 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 19:49:44 +0200 (MET DST) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 265F714FA6 for ; Wed, 27 Oct 1999 10:49:11 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (ind.alcatel.com 2.3 [OUT])) id KAA09754; Wed, 27 Oct 1999 10:48:36 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id KAA03831; Wed, 27 Oct 1999 10:48:35 -0700 Received: from softweyr.com (dyn7.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA06615; Wed, 27 Oct 99 10:48:26 PDT Message-Id: <38173AF2.BD8D6486@softweyr.com> Date: Wed, 27 Oct 1999 11:48:34 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Christopher Masto Cc: freebsd-arch@freebsd.org Subject: Re: Racing interrupts References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <3815F2A0.FA3442F4@softweyr.com> <19991027040510.A534@netmonger.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Masto wrote: > > Given where we are right now in -current, would it be sensible to > consider finding a way to disable devices before ejecting them? I'm > plenty willing to have to "shut down" a card before removing it, but > having no way to do so at the moment, I will shortly be fully shutting > down the laptop I'm writing this on just so I can put it away. For network cards, we could certainly make "ifconfig down" put the card into an acceptable state for eject. In fact, it probably already does. For SCSI/floppy interfaces, unmounting any filesystems and closing any references to the raw devices would suffice. -- "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 Wed Oct 27 11:35:41 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 14898154A0 for ; Wed, 27 Oct 1999 11:35:25 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA13282 for ; Wed, 27 Oct 1999 20:35:24 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA28335 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 20:35:23 +0200 (MET DST) Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id 3273914BF7 for ; Wed, 27 Oct 1999 11:34:56 -0700 (PDT) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id OAA21968; Wed, 27 Oct 1999 14:34:56 -0400 (EDT) Message-ID: <19991027143456.A21292@netmonger.net> Date: Wed, 27 Oct 1999 14:34:56 -0400 From: Christopher Masto To: freebsd-arch@freebsd.org Subject: Re: Racing interrupts Mail-Followup-To: freebsd-arch@FreeBSD.ORG References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <3815F2A0.FA3442F4@softweyr.com> <19991027040510.A534@netmonger.net> <38173AF2.BD8D6486@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <38173AF2.BD8D6486@softweyr.com>; from Wes Peters on Wed, Oct 27, 1999 at 11:48:34AM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Oct 27, 1999 at 11:48:34AM -0600, Wes Peters wrote: > Christopher Masto wrote: > > > > Given where we are right now in -current, would it be sensible to > > consider finding a way to disable devices before ejecting them? I'm > > plenty willing to have to "shut down" a card before removing it, but > > having no way to do so at the moment, I will shortly be fully shutting > > down the laptop I'm writing this on just so I can put it away. > > For network cards, we could certainly make "ifconfig down" put the card > into an acceptable state for eject. In fact, it probably already does. Checked that last night.. it locks up even if "ifconfig down"ed. Presumably there's a bug in the eject handling, not in the card disappearing without being disabled. -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- 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 Oct 27 11:58:21 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3D5421503E for ; Wed, 27 Oct 1999 11:58:18 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA13538 for ; Wed, 27 Oct 1999 20:58:17 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA28433 for freebsd-arch@freebsd.org; Wed, 27 Oct 1999 20:58:16 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B4F3E14DE2 for ; Wed, 27 Oct 1999 11:57:12 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA41009; Wed, 27 Oct 1999 12:57:11 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA68374; Wed, 27 Oct 1999 12:58:22 -0600 (MDT) Message-Id: <199910271858.MAA68374@harmony.village.org> To: Christopher Masto Subject: Re: Racing interrupts Cc: freebsd-arch@freebsd.org In-reply-to: Your message of "Wed, 27 Oct 1999 14:34:56 EDT." <19991027143456.A21292@netmonger.net> References: <19991027143456.A21292@netmonger.net> <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <3815F2A0.FA3442F4@softweyr.com> <19991027040510.A534@netmonger.net> <38173AF2.BD8D6486@softweyr.com> Date: Wed, 27 Oct 1999 12:58:21 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19991027143456.A21292@netmonger.net> Christopher Masto writes: : Checked that last night.. it locks up even if "ifconfig down"ed. : Presumably there's a bug in the eject handling, not in the card : disappearing without being disabled. There's a bug in card eject and suspend right now. I broke it :-(. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 17:35:33 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2D5BD15066 for ; Wed, 27 Oct 1999 17:35:20 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA17153 for ; Thu, 28 Oct 1999 02:35:17 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA29847 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 02:35:17 +0200 (MET DST) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 8917814F8E for ; Wed, 27 Oct 1999 17:34:26 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id KAA19370; Thu, 28 Oct 1999 10:04:11 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199910271627.KAA64604@harmony.village.org> Date: Thu, 28 Oct 1999 10:04:10 +0930 (CST) From: "Daniel O'Connor" To: Warner Losh Subject: Re: Racing interrupts Cc: freebsd-arch@freebsd.org, Christopher Masto Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27-Oct-99 Warner Losh wrote: > It depends. You need to detach the driver from the system, and then > you can safely remove power from the card. This usually will generate > an unfielded interrupt (since the card will have detached its ISR from > the vector), but that's usually the worst of it. Hmm.. Well.. Does this happen in PAO? ie if I tell it to power off the card does it DTRT? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 20:35: 7 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8186014F06 for ; Wed, 27 Oct 1999 20:35:05 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA18350 for ; Thu, 28 Oct 1999 05:35:03 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA30530 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 05:35:03 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 6BED314CD0 for ; Wed, 27 Oct 1999 20:34:56 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA42689; Wed, 27 Oct 1999 21:34:51 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id VAA71194; Wed, 27 Oct 1999 21:36:05 -0600 (MDT) Message-Id: <199910280336.VAA71194@harmony.village.org> To: "Daniel O'Connor" Subject: Re: Racing interrupts Cc: freebsd-arch@freebsd.org, Christopher Masto In-reply-to: Your message of "Thu, 28 Oct 1999 10:04:10 +0930." References: Date: Wed, 27 Oct 1999 21:36:05 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Daniel O'Connor" writes: : Hmm.. Well.. Does this happen in PAO? : ie if I tell it to power off the card does it DTRT? Yes. And -current did the right thing until I broke it recently. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 20:39:32 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5222914F06 for ; Wed, 27 Oct 1999 20:39:29 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA18383 for ; Thu, 28 Oct 1999 05:39:28 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA30562 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 05:39:28 +0200 (MET DST) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 7FA5914F06 for ; Wed, 27 Oct 1999 20:39:18 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id NAA21506; Thu, 28 Oct 1999 13:09:05 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199910280336.VAA71194@harmony.village.org> Date: Thu, 28 Oct 1999 13:09:05 +0930 (CST) From: "Daniel O'Connor" To: Warner Losh Subject: Re: Racing interrupts Cc: Christopher Masto , freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 28-Oct-99 Warner Losh wrote: > : Hmm.. Well.. Does this happen in PAO? > : ie if I tell it to power off the card does it DTRT? > Yes. And -current did the right thing until I broke it recently. Ahh.. Still.. I sense the potential for a doc app for window maker here :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 20:56:59 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 662AE14C85 for ; Wed, 27 Oct 1999 20:56:56 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA18499 for ; Thu, 28 Oct 1999 05:56:55 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA30638 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 05:56:55 +0200 (MET DST) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 848C614C85 for ; Wed, 27 Oct 1999 20:56:48 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40328>; Thu, 28 Oct 1999 13:51:45 +1000 Content-return: prohibited Date: Thu, 28 Oct 1999 13:56:40 +1000 From: Peter Jeremy Subject: Storing small files in inodes To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct28.135145est.40328@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd like to float the possibility of storing small (<= 60 bytes) files and maybe directories inside inodes, in the same manner as short symlinks are stored. Looking through my main system, about 12.5% of inodes are allocated to short files and a further 3.5% are allocated to short directories. Advantages: - Faster access to the file (since the inode contains the contents, rather than a pointer to the contents). - In my case, saving about 1.3% of disk space though this would increase if I moved to a larger fragment size. Disadvantages: - Filesystem media incompatability Programs affected (based on the programs that have special handling for symlinks via MAXSYMLINKLEN or fs_maxsymlinklen): - fsck(8), fsdb(8) and dump(8) - libstand/ufs.c The kernel handling would be more complex than for symlinks because files additionally have the ability to be mmap'd and updated, but I don't believe the problems are insurmountable. Comments? Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 22:35:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id AE9FA14EC1 for ; Wed, 27 Oct 1999 22:35:35 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA19246 for ; Thu, 28 Oct 1999 07:35:34 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA30960 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 07:35:34 +0200 (MET DST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id 3E8D014EC1 for ; Wed, 27 Oct 1999 22:35:27 -0700 (PDT) (envelope-from michael.schuster@germany.sun.com) Received: from emuc05-home.Germany.Sun.COM ([129.157.51.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA03639; Wed, 27 Oct 1999 22:35:21 -0700 (PDT) Received: from germany.sun.com (hacker [129.157.167.97]) by emuc05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id HAA16360; Thu, 28 Oct 1999 07:35:19 +0200 (MET DST) Message-ID: <3817E098.3D6EB04B@germany.sun.com> Date: Thu, 28 Oct 1999 07:35:20 +0200 From: Michael Schuster - TSC SunOS Germany Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: peter.jeremy@alcatel.com.au Cc: freebsd-arch@freebsd.org Subject: Re: Storing small files in inodes References: <99Oct28.135145est.40328@border.alcanet.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Jeremy wrote: > > I'd like to float the possibility of storing small (<= 60 bytes) files > and maybe directories inside inodes, in the same manner as short > symlinks are stored. > > Looking through my main system, about 12.5% of inodes are allocated > to short files and a further 3.5% are allocated to short directories. .... > Comments? sounds good & interesting. I think there's other people who are thinking along those lines as well, so I guess you're in good company :-) > Peter my 2 bits Michael -- Michael Schuster / Michael.Schuster@germany.sun.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 22:51:30 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9A98614E44 for ; Wed, 27 Oct 1999 22:51:28 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA19378 for ; Thu, 28 Oct 1999 07:51:27 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA31016 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 07:51:27 +0200 (MET DST) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id BA0CF14C89 for ; Wed, 27 Oct 1999 22:50:00 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id WAA19025; Wed, 27 Oct 1999 22:48:41 -0700 Date: Wed, 27 Oct 1999 22:48:39 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Michael Schuster - TSC SunOS Germany Cc: peter.jeremy@alcatel.com.au, freebsd-arch@freebsd.org Subject: Re: Storing small files in inodes In-Reply-To: <3817E098.3D6EB04B@germany.sun.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 Can we start thinking about fat inodes too? On Thu, 28 Oct 1999, Michael Schuster - TSC SunOS Germany wrote: > Peter Jeremy wrote: > > > > I'd like to float the possibility of storing small (<= 60 bytes) files > > and maybe directories inside inodes, in the same manner as short > > symlinks are stored. > > > > Looking through my main system, about 12.5% of inodes are allocated > > to short files and a further 3.5% are allocated to short directories. > .... > > > Comments? > > sounds good & interesting. I think there's other people who are thinking > along those lines as well, so I guess you're in good company :-) > > > Peter > > my 2 bits > Michael > -- > Michael Schuster / Michael.Schuster@germany.sun.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 23: 8:28 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0B50214E44 for ; Wed, 27 Oct 1999 23:08:22 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA19528 for ; Thu, 28 Oct 1999 08:08:21 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA31113 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 08:08:21 +0200 (MET DST) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id D124214E44 for ; Wed, 27 Oct 1999 23:08:06 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40335>; Thu, 28 Oct 1999 16:02:57 +1000 Content-return: prohibited Date: Thu, 28 Oct 1999 16:07:55 +1000 From: Peter Jeremy Subject: Re: Storing small files in inodes In-reply-to: To: Matthew Jacob Cc: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct28.160257est.40335@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <3817E098.3D6EB04B@germany.sun.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-28 15:48:39 +1000, Matthew Jacob wrote: >Can we start thinking about fat inodes too? I personally think they're fat enough as it is - by default they occupy about 3% of the disk (though I generally only create about 1/2 the default number). Doubling the size of the inode would probably be reasonable if some of the space was available for storing small files. I presume you're thinking of additional space to store ACLs. Given that ACL's are optional, vary widely in side and can reasonably be shared, I'd prefer to see them stored outside the inode. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 27 23:29:29 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3C28414D37 for ; Wed, 27 Oct 1999 23:29:26 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA19748 for ; Thu, 28 Oct 1999 08:29:25 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA31187 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 08:29:25 +0200 (MET DST) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D667114D37 for ; Wed, 27 Oct 1999 23:28:46 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id XAA19241; Wed, 27 Oct 1999 23:28:38 -0700 Date: Wed, 27 Oct 1999 23:28:36 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Peter Jeremy Cc: freebsd-arch@freebsd.org Subject: Re: Storing small files in inodes In-Reply-To: <99Oct28.160257est.40335@border.alcanet.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 Thu, 28 Oct 1999, Peter Jeremy wrote: > On 1999-Oct-28 15:48:39 +1000, Matthew Jacob wrote: > >Can we start thinking about fat inodes too? > > I personally think they're fat enough as it is - by default they > occupy about 3% of the disk (though I generally only create about > 1/2 the default number). Doubling the size of the inode would > probably be reasonable if some of the space was available for > storing small files. > > I presume you're thinking of additional space to store ACLs. Given > that ACL's are optional, vary widely in side and can reasonably be > shared, I'd prefer to see them stored outside the inode. Not really ACLs. I'm thinking of head and tail residency for terabyte datasets (for HSM applications). This was discussed extensively in NetBSD a few months ago. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 1: 9: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 885F414CB3 for ; Thu, 28 Oct 1999 01:08:59 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA21335 for ; Thu, 28 Oct 1999 10:08:57 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA31593 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 10:08:57 +0200 (MET DST) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (Postfix) with ESMTP id E784E14CB3 for ; Thu, 28 Oct 1999 01:08:44 -0700 (PDT) (envelope-from rb@gid.co.uk) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.9.2/8.8.7) with UUCP id JAA14043; Thu, 28 Oct 1999 09:07:32 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from grimbling (grimbling [192.168.0.250]) by cwagate (8.6.12/8.6.12) with SMTP id IAA41755; Thu, 28 Oct 1999 08:12:14 +0100 Message-Id: <3.0.6.32.19991028081210.0079b7a0@192.168.255.1> X-Sender: rbmail@192.168.255.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 28 Oct 1999 08:12:10 +0100 To: peter.jeremy@alcatel.com.au From: Bob Bishop Subject: Re: Storing small files in inodes Cc: freebsd-arch@freebsd.org In-Reply-To: <99Oct28.135145est.40328@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, At 01:56 PM 10/28/99 +1000, Peter Jeremy wrote: >I'd like to float the possibility of storing small (<= 60 bytes) files >and maybe directories inside inodes [etc] This is a very old idea - ISTR seeing it in a paper over 10 years ago, unfortunately I don't have a reference to hand. Might be worth revisiting. -- Bob Bishop +44 118 977 4017 rb@gid.co.uk fax +44 118 989 4254 (0800-1800 UK) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 2:33:56 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 495CA14ED3 for ; Thu, 28 Oct 1999 02:33:47 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA23052 for ; Thu, 28 Oct 1999 11:33:45 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA31990 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 11:33:45 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id C0B4714F06 for ; Thu, 28 Oct 1999 02:33:26 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id CAA26105; Thu, 28 Oct 1999 02:33:22 -0700 (PDT) Date: Thu, 28 Oct 1999 02:33:22 -0700 (PDT) From: Julian Elischer To: peter.jeremy@alcatel.com.au Cc: freebsd-arch@freebsd.org Subject: Re: Storing small files in inodes In-Reply-To: <99Oct28.135145est.40328@border.alcanet.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 These are called nanofiles. Bill Jolitz talked about them in a talk he did on BSD in '91 In effect we already do that.. note how malloc(3) uses a symlink to read its config info :-). On Thu, 28 Oct 1999, Peter Jeremy wrote: > I'd like to float the possibility of storing small (<= 60 bytes) files > and maybe directories inside inodes, in the same manner as short > symlinks are stored. > > Looking through my main system, about 12.5% of inodes are allocated > to short files and a further 3.5% are allocated to short directories. > > Advantages: > - Faster access to the file (since the inode contains the contents, > rather than a pointer to the contents). > - In my case, saving about 1.3% of disk space though this would > increase if I moved to a larger fragment size. > > Disadvantages: > - Filesystem media incompatability we'd have the code to read it turned on by default for 6 months before we turned on the default to write them. > > Programs affected (based on the programs that have special handling > for symlinks via MAXSYMLINKLEN or fs_maxsymlinklen): > - fsck(8), fsdb(8) and dump(8) > - libstand/ufs.c > > The kernel handling would be more complex than for symlinks because > files additionally have the ability to be mmap'd and updated, but I > don't believe the problems are insurmountable. > > Comments? I vaguely remember a paper on the topic. Maybe kirk can tell us more. > > Peter > -- > Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au > Alcatel Australia Limited > 41 Mandible St Phone: +61 2 9690 5019 > ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 5:57:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3F95414C21 for ; Thu, 28 Oct 1999 05:57:47 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA26795 for ; Thu, 28 Oct 1999 14:57:46 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA32616 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 14:57:45 +0200 (MET DST) Received: by hub.freebsd.org (Postfix, from userid 608) id 8F93C14C21; Thu, 28 Oct 1999 05:57:36 -0700 (PDT) From: "Jonathan M. Bresler" To: julian@whistle.com Cc: peter.jeremy@alcatel.com.au, freebsd-arch@freebsd.org In-reply-to: (message from Julian Elischer on Thu, 28 Oct 1999 02:33:22 -0700 (PDT)) Subject: Re: Storing small files in inodes Message-Id: <19991028125736.8F93C14C21@hub.freebsd.org> Date: Thu, 28 Oct 1999 05:57:36 -0700 (PDT) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG storing small files in the inode solves the .file problem. during his second tutorial at FreeBSDCon, kirk spoke of trying to combine the .files into a single file.....went over like a lead balloon at the time. sounds like a good idea to me. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 10:36: 8 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2D72914D10 for ; Thu, 28 Oct 1999 10:36:04 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA00979 for ; Thu, 28 Oct 1999 19:36:03 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA33938 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 19:35:47 +0200 (MET DST) Received: from io.yi.org (24.66.174.118.bc.wave.home.com [24.66.174.118]) by hub.freebsd.org (Postfix) with ESMTP id E97CD14D10 for ; Thu, 28 Oct 1999 10:35:28 -0700 (PDT) (envelope-from jake@checker.org) Received: from io.yi.org (localhost [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id C12031FD6 for ; Thu, 28 Oct 1999 10:35:29 -0700 (PDT) X-Mailer: exmh version 2.1.0 09/18/1999 To: arch@freebsd.org Subject: rfork patch, please comment Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1783049920" Date: Thu, 28 Oct 1999 10:35:29 -0700 From: Jake Burkholder Message-Id: <19991028173529.C12031FD6@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multipart MIME message. --==_Exmh_1783049920 Content-Type: text/plain; charset=us-ascii Hi, I've made a patch that adds linux 'clone' style support to rfork, and I'd like to hear opinions on whether this is an ok way to do it. It consists of adding varargs to rfork, and passing in a new stack pointer and return address, so the two processes don't try to use the same stack on return. Should this just be tacked on to rfork? Should a new system call be added? (tfork? ffork? lfork? clone?) Are 2 arguments enough? do we want to also pass in a sigparent? Am I on the wrong track completely, and should this just be added to libc ala Matt Dillon's ffork example? Is this portable enough? (Does anyone know what the corresponding cpu_set_rfork_handler() for alpha should look like?) I had problems with 251 STD BSD { int rfork(int flags, void (*func)(void*), void *stack); } in syscalls.master, so I bogusly made it void *func . Does this need a typedef? (Maybe this should go to hackers, the audience here seemed smaller and more friendly :) ). I'm using a recent -current, I don't know how this will apply to anything else. Recompile kernel, and then cd /usr/src; make includes. Thank you. --==_Exmh_1783049920 Content-Type: text/plain ; name="rfork.diff"; charset=us-ascii Content-Description: rfork.diff Content-Disposition: attachment; filename="rfork.diff" Index: include/unistd.h =================================================================== RCS file: /home/ncvs/src/include/unistd.h,v retrieving revision 1.27 diff -c -r1.27 unistd.h *** unistd.h 1999/07/16 06:28:51 1.27 --- unistd.h 1999/10/28 15:24:19 *************** *** 165,171 **** int readlink __P((const char *, char *, int)); int reboot __P((int)); int revoke __P((const char *)); ! pid_t rfork __P((int)); int rresvport __P((int *)); int ruserok __P((const char *, int, const char *, const char *)); char *sbrk __P((int)); --- 165,171 ---- int readlink __P((const char *, char *, int)); int reboot __P((int)); int revoke __P((const char *)); ! pid_t rfork __P((int, ...)); int rresvport __P((int *)); int ruserok __P((const char *, int, const char *, const char *)); char *sbrk __P((int)); Index: sys/alpha/alpha/vm_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/vm_machdep.c,v retrieving revision 1.22 diff -c -r1.22 vm_machdep.c *** vm_machdep.c 1999/09/20 19:08:47 1.22 --- vm_machdep.c 1999/10/28 16:28:33 *************** *** 231,236 **** --- 231,247 ---- p->p_addr->u_pcb.pcb_context[2] = (u_long) arg; } + void + cpu_set_rfork_handler(p, func, stack) + struct proc *p; + void (*func) __P((void *)); + void *stack; + { + /* XXX help! I'm guessing here. */ + p->p_md.md_tf->tf_regs[FRAME_RA] = (u_long) func; + p->p_md.md_tf->tf_regs[FRAME_SP] = (u_long) stack; + } + /* * cpu_exit is called as the last action during exit. * We release the address space of the process, block interrupts, Index: sys/i386/i386/vm_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/vm_machdep.c,v retrieving revision 1.128 diff -c -r1.128 vm_machdep.c *** vm_machdep.c 1999/10/11 14:50:03 1.128 --- vm_machdep.c 1999/10/28 15:30:35 *************** *** 205,210 **** --- 205,220 ---- } void + cpu_set_rfork_handler(p, func, stack) + struct proc *p; + void (*func) __P((void *)); + void *stack; + { + p->p_md.md_regs->tf_eip = (int) func; + p->p_md.md_regs->tf_esp = (int) stack; + } + + void cpu_exit(p) register struct proc *p; { Index: sys/kern/init_sysent.c =================================================================== RCS file: /home/ncvs/src/sys/kern/init_sysent.c,v retrieving revision 1.73 diff -c -r1.73 init_sysent.c *** init_sysent.c 1999/10/12 09:33:51 1.73 --- init_sysent.c 1999/10/28 15:40:06 *************** *** 2,8 **** * System call switch table. * * DO NOT EDIT-- this file is automatically generated. ! * $FreeBSD: src/sys/kern/init_sysent.c,v 1.73 1999/10/12 09:33:51 marcel Exp $ * created from FreeBSD: src/sys/kern/syscalls.master,v 1.66 1999/10/12 09:29:53 marcel Exp */ --- 2,8 ---- * System call switch table. * * DO NOT EDIT-- this file is automatically generated. ! * $FreeBSD$ * created from FreeBSD: src/sys/kern/syscalls.master,v 1.66 1999/10/12 09:29:53 marcel Exp */ *************** *** 271,277 **** { 0, (sy_call_t *)nosys }, /* 248 = nosys */ { 0, (sy_call_t *)nosys }, /* 249 = nosys */ { 3, (sy_call_t *)minherit }, /* 250 = minherit */ ! { 1, (sy_call_t *)rfork }, /* 251 = rfork */ { 3, (sy_call_t *)openbsd_poll }, /* 252 = openbsd_poll */ { 0, (sy_call_t *)issetugid }, /* 253 = issetugid */ { 3, (sy_call_t *)lchown }, /* 254 = lchown */ --- 271,277 ---- { 0, (sy_call_t *)nosys }, /* 248 = nosys */ { 0, (sy_call_t *)nosys }, /* 249 = nosys */ { 3, (sy_call_t *)minherit }, /* 250 = minherit */ ! { 3, (sy_call_t *)rfork }, /* 251 = rfork */ { 3, (sy_call_t *)openbsd_poll }, /* 252 = openbsd_poll */ { 0, (sy_call_t *)issetugid }, /* 253 = issetugid */ { 3, (sy_call_t *)lchown }, /* 254 = lchown */ Index: sys/kern/kern_fork.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_fork.c,v retrieving revision 1.66 diff -c -r1.66 kern_fork.c *** kern_fork.c 1999/10/11 15:19:08 1.66 --- kern_fork.c 1999/10/28 16:28:50 *************** *** 129,135 **** error = fork1(p, uap->flags, &p2); if (error == 0) { ! p->p_retval[0] = p2 ? p2->p_pid : 0; p->p_retval[1] = 0; } return error; --- 129,141 ---- error = fork1(p, uap->flags, &p2); if (error == 0) { ! if (p2) { ! p->p_retval[0] = p2->p_pid; ! if (uap->flags & RFMEM) ! cpu_set_rfork_handler(p2, uap->func, uap->stack); ! } else { ! p->p_retval[0] = 0; ! } p->p_retval[1] = 0; } return error; Index: sys/kern/syscalls.c =================================================================== RCS file: /home/ncvs/src/sys/kern/syscalls.c,v retrieving revision 1.66 diff -c -r1.66 syscalls.c *** syscalls.c 1999/10/12 09:33:51 1.66 --- syscalls.c 1999/10/28 15:40:06 *************** *** 2,8 **** * System call names. * * DO NOT EDIT-- this file is automatically generated. ! * $FreeBSD: src/sys/kern/syscalls.c,v 1.66 1999/10/12 09:33:51 marcel Exp $ * created from FreeBSD: src/sys/kern/syscalls.master,v 1.66 1999/10/12 09:29:53 marcel Exp */ --- 2,8 ---- * System call names. * * DO NOT EDIT-- this file is automatically generated. ! * $FreeBSD$ * created from FreeBSD: src/sys/kern/syscalls.master,v 1.66 1999/10/12 09:29:53 marcel Exp */ Index: sys/kern/syscalls.master =================================================================== RCS file: /home/ncvs/src/sys/kern/syscalls.master,v retrieving revision 1.66 diff -c -r1.66 syscalls.master *** syscalls.master 1999/10/12 09:29:53 1.66 --- syscalls.master 1999/10/28 15:39:52 *************** *** 380,386 **** 249 UNIMPL NOHIDE nosys ; syscall numbers initially used in OpenBSD 250 STD BSD { int minherit(void *addr, size_t len, int inherit); } ! 251 STD BSD { int rfork(int flags); } 252 STD BSD { int openbsd_poll(struct pollfd *fds, u_int nfds, \ int timeout); } 253 STD BSD { int issetugid(void); } --- 380,386 ---- 249 UNIMPL NOHIDE nosys ; syscall numbers initially used in OpenBSD 250 STD BSD { int minherit(void *addr, size_t len, int inherit); } ! 251 STD BSD { int rfork(int flags, void *func, void *stack); } 252 STD BSD { int openbsd_poll(struct pollfd *fds, u_int nfds, \ int timeout); } 253 STD BSD { int issetugid(void); } Index: sys/sys/proc.h =================================================================== RCS file: /home/ncvs/src/sys/sys/proc.h,v retrieving revision 1.90 diff -c -r1.90 proc.h *** proc.h 1999/10/11 20:33:16 1.90 --- proc.h 1999/10/28 15:24:40 *************** *** 401,406 **** --- 401,407 ---- void exit1 __P((struct proc *, int)) __dead2; void cpu_fork __P((struct proc *, struct proc *)); void cpu_set_fork_handler __P((struct proc *, void (*)(void *), void *)); + void cpu_set_rfork_handler __P((struct proc *, void (*)(void *), void *)); int fork1 __P((struct proc *, int, struct proc **)); int trace_req __P((struct proc *)); void cpu_wait __P((struct proc *)); Index: sys/sys/syscall-hide.h =================================================================== RCS file: /home/ncvs/src/sys/sys/syscall-hide.h,v retrieving revision 1.60 diff -c -r1.60 syscall-hide.h *** syscall-hide.h 1999/10/12 09:33:52 1.60 --- syscall-hide.h 1999/10/28 15:40:06 *************** *** 2,8 **** * System call hiders. * * DO NOT EDIT-- this file is automatically generated. ! * $FreeBSD: src/sys/sys/syscall-hide.h,v 1.60 1999/10/12 09:33:52 marcel Exp $ * created from FreeBSD: src/sys/kern/syscalls.master,v 1.66 1999/10/12 09:29:53 marcel Exp */ --- 2,8 ---- * System call hiders. * * DO NOT EDIT-- this file is automatically generated. ! * $FreeBSD$ * created from FreeBSD: src/sys/kern/syscalls.master,v 1.66 1999/10/12 09:29:53 marcel Exp */ Index: sys/sys/syscall.h =================================================================== RCS file: /home/ncvs/src/sys/sys/syscall.h,v retrieving revision 1.64 diff -c -r1.64 syscall.h *** syscall.h 1999/10/12 09:33:52 1.64 --- syscall.h 1999/10/28 15:40:06 *************** *** 2,8 **** * System call numbers. * * DO NOT EDIT-- this file is automatically generated. ! * $FreeBSD: src/sys/sys/syscall.h,v 1.64 1999/10/12 09:33:52 marcel Exp $ * created from FreeBSD: src/sys/kern/syscalls.master,v 1.66 1999/10/12 09:29:53 marcel Exp */ --- 2,8 ---- * System call numbers. * * DO NOT EDIT-- this file is automatically generated. ! * $FreeBSD$ * created from FreeBSD: src/sys/kern/syscalls.master,v 1.66 1999/10/12 09:29:53 marcel Exp */ Index: sys/sys/syscall.mk =================================================================== RCS file: /home/ncvs/src/sys/sys/syscall.mk,v retrieving revision 1.18 diff -c -r1.18 syscall.mk *** syscall.mk 1999/10/12 09:33:53 1.18 --- syscall.mk 1999/10/28 15:40:06 *************** *** 1,6 **** # FreeBSD system call names. # DO NOT EDIT-- this file is automatically generated. ! # $FreeBSD: src/sys/sys/syscall.mk,v 1.18 1999/10/12 09:33:53 marcel Exp $ # created from FreeBSD: src/sys/kern/syscalls.master,v 1.66 1999/10/12 09:29:53 marcel Exp MIASM = \ syscall.o \ --- 1,6 ---- # FreeBSD system call names. # DO NOT EDIT-- this file is automatically generated. ! # $FreeBSD$ # created from FreeBSD: src/sys/kern/syscalls.master,v 1.66 1999/10/12 09:29:53 marcel Exp MIASM = \ syscall.o \ Index: sys/sys/sysproto.h =================================================================== RCS file: /home/ncvs/src/sys/sys/sysproto.h,v retrieving revision 1.53 diff -c -r1.53 sysproto.h *** sysproto.h 1999/10/12 09:33:53 1.53 --- sysproto.h 1999/10/28 15:40:06 *************** *** 2,8 **** * System call prototypes. * * DO NOT EDIT-- this file is automatically generated. ! * $FreeBSD: src/sys/sys/sysproto.h,v 1.53 1999/10/12 09:33:53 marcel Exp $ * created from FreeBSD: src/sys/kern/syscalls.master,v 1.66 1999/10/12 09:29:53 marcel Exp */ --- 2,8 ---- * System call prototypes. * * DO NOT EDIT-- this file is automatically generated. ! * $FreeBSD$ * created from FreeBSD: src/sys/kern/syscalls.master,v 1.66 1999/10/12 09:29:53 marcel Exp */ *************** *** 726,731 **** --- 726,733 ---- }; struct rfork_args { int flags; char flags_[PAD_(int)]; + void * func; char func_[PAD_(void *)]; + void * stack; char stack_[PAD_(void *)]; }; struct openbsd_poll_args { struct pollfd * fds; char fds_[PAD_(struct pollfd *)]; --==_Exmh_1783049920 Content-Type: text/plain ; name="rfork.c"; charset=us-ascii Content-Description: rfork.c Content-Disposition: attachment; filename="rfork.c" #include #include void child(void *arg) { int *i = arg; for(;;) ++(*i); } int main(int ac, char **av) { char *p, stack[4096]; int i = 0; p = stack + sizeof(stack) - sizeof(int); *(int **)p = &i; p -= sizeof(int *); rfork(RFPROC | RFMEM, child, p); for(;;) { fprintf(stderr, "%d\n", i); sleep(1); } return 0; } --==_Exmh_1783049920-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 10:54:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8981B14BF4 for ; Thu, 28 Oct 1999 10:54:51 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA01198 for ; Thu, 28 Oct 1999 19:54:50 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA34098 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 19:54:50 +0200 (MET DST) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id D4B9514BF4 for ; Thu, 28 Oct 1999 10:54:40 -0700 (PDT) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id TAA30185 for arch@FreeBSD.org; Thu, 28 Oct 1999 19:54:15 +0200 (CEST) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Thu, 28 Oct 1999 19:54:07 +0200 From: Marcel Moolenaar Message-ID: <38188DBF.FCD05915@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <19991028173529.C12031FD6@io.yi.org> Subject: Re: rfork patch, please comment Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [No time yet to dig into this in more detail] Jake Burkholder wrote: > I've made a patch that adds linux 'clone' style support > to rfork, and I'd like to hear opinions on whether this > is an ok way to do it. Does this improve the support for clone in the Linuxulator? -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 11:10:43 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 82C7D14BDD for ; Thu, 28 Oct 1999 11:10:37 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA01344 for ; Thu, 28 Oct 1999 20:10:36 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA34201 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 20:10:35 +0200 (MET DST) Received: from io.yi.org (24.66.174.118.bc.wave.home.com [24.66.174.118]) by hub.freebsd.org (Postfix) with ESMTP id 48FCA14BDD for ; Thu, 28 Oct 1999 11:10:28 -0700 (PDT) (envelope-from jake@checker.org) Received: from io.yi.org (localhost [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id A85ED1FD7; Thu, 28 Oct 1999 11:10:29 -0700 (PDT) X-Mailer: exmh version 2.1.0 09/18/1999 To: Marcel Moolenaar Cc: freebsd-arch@freebsd.org Subject: Re: rfork patch, please comment In-reply-to: Your message of "Thu, 28 Oct 1999 19:54:07 +0200." <38188DBF.FCD05915@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Oct 1999 11:10:29 -0700 From: Jake Burkholder Message-Id: <19991028181029.A85ED1FD7@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > [No time yet to dig into this in more detail] > > Jake Burkholder wrote: > > > I've made a patch that adds linux 'clone' style support > > to rfork, and I'd like to hear opinions on whether this > > is an ok way to do it. > > Does this improve the support for clone in the Linuxulator? No, there is already some support there. That's where I got the idea, see /usr/src/sys/i386/linux/linux_misc.c:linux_clone. What it does, as I see it, is open the door for native kernel threads, which of course still requires a thread-safe libc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 12: 1: 9 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 497BB152AB for ; Thu, 28 Oct 1999 12:00:55 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA01831 for ; Thu, 28 Oct 1999 21:00:54 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA34350 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 21:00:54 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id B9BD8151C6 for ; Thu, 28 Oct 1999 11:59:51 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id LAA41770; Thu, 28 Oct 1999 11:59:46 -0700 (PDT) Date: Thu, 28 Oct 1999 11:59:46 -0700 (PDT) From: Julian Elischer To: Jake Burkholder Cc: Marcel Moolenaar , freebsd-arch@freebsd.org Subject: Re: rfork patch, please comment In-Reply-To: <19991028181029.A85ED1FD7@io.yi.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 I know I've been a fan of using rfork for native threads, (and all the support that we need for a linuxthreads is already there (see the linuxthread PORT to freebsd)). But I was speakin gwith terry the other day and he managed to convince me that there is an even better way that we could do this. It's really quite elegant. On Thu, 28 Oct 1999, Jake Burkholder wrote: > > [No time yet to dig into this in more detail] > > > > Jake Burkholder wrote: > > > > > I've made a patch that adds linux 'clone' style support > > > to rfork, and I'd like to hear opinions on whether this > > > is an ok way to do it. > > > > Does this improve the support for clone in the Linuxulator? > > No, there is already some support there. That's where I got the idea, > see /usr/src/sys/i386/linux/linux_misc.c:linux_clone. > > What it does, as I see it, is open the door for native kernel > threads, which of course still requires a thread-safe libc. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 12:16:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4B7DE15109 for ; Thu, 28 Oct 1999 12:16:46 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA01991 for ; Thu, 28 Oct 1999 21:16:45 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA34440 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 21:16:44 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 202CD14C98 for ; Thu, 28 Oct 1999 12:16:28 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA11225; Thu, 28 Oct 1999 13:16:16 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA29823; Thu, 28 Oct 1999 13:16:15 -0600 Date: Thu, 28 Oct 1999 13:16:15 -0600 Message-Id: <199910281916.NAA29823@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Jake Burkholder , Marcel Moolenaar , freebsd-arch@freebsd.org Subject: Re: rfork patch, please comment In-Reply-To: References: <19991028181029.A85ED1FD7@io.yi.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I know I've been a fan of using rfork for native threads, > (and all the support that we need for a linuxthreads is already there > (see the linuxthread PORT to freebsd)). But I was speakin gwith terry the > other day and he managed to convince me that there is an even better way > that we could do this. > > It's really quite elegant. And that elegant solution would be.........??? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 12:27: 0 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A72C614CF7 for ; Thu, 28 Oct 1999 12:26:51 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA02089 for ; Thu, 28 Oct 1999 21:26:50 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA34481 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 21:26:50 +0200 (MET DST) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (Postfix) with ESMTP id 982A714CF7 for ; Thu, 28 Oct 1999 12:26:41 -0700 (PDT) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id MAA25987; Thu, 28 Oct 1999 12:26:40 -0700 (PDT) (envelope-from sef) Date: Thu, 28 Oct 1999 12:26:40 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199910281926.MAA25987@kithrup.com> To: freebsd-arch@freebsd.org Reply-To: freebsd-arch@freebsd.org Subject: Re: Storing small files in inodes In-Reply-To: <3.0.6.32.19991028081210.0079b7a0.kithrup.freebsd.freebsd-arch@192.168.255.1> References: <99Oct28.135145est.40328@border.alcanet.com.au> Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <3.0.6.32.19991028081210.0079b7a0.kithrup.freebsd.freebsd-arch@192.168.255.1> you write: >This is a very old idea - ISTR seeing it in a paper over 10 years ago, >unfortunately I don't have a reference to hand. Might be worth revisiting. Amdahl was doing this in UTS a long time ago. To the best of my knowledge, they did not have any problems with it. And we're _already_ doing it for a particular class of files -- symlinks. My only concern is that I'd like an option to disable it on a per-filesystem basis. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 13: 0:12 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id AFCFB14D03 for ; Thu, 28 Oct 1999 13:00:01 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA02450 for ; Thu, 28 Oct 1999 21:59:56 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA34656 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 21:59:56 +0200 (MET DST) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id CFFF814DD0 for ; Thu, 28 Oct 1999 12:59:28 -0700 (PDT) (envelope-from deischen@gdeb.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id PAA27828; Thu, 28 Oct 1999 15:33:24 -0400 (EDT) Received: from gdeb.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id PAA35521; Thu, 28 Oct 1999 15:57:53 -0400 (EDT) (envelope-from deischen@gdeb.com) Message-ID: <3818AAC0.D5587B9E@gdeb.com> Date: Thu, 28 Oct 1999 15:57:52 -0400 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: julian@whistle.com Cc: marcel@scc.nl, jake@checker.org, freebsd-arch@freebsd.org Subject: Native threads (was Re: rfork patch, please comment) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > I know I've been a fan of using rfork for native threads, > (and all the support that we need for a linuxthreads is already there > (see the linuxthread PORT to freebsd)). But I was speakin gwith terry the > other day and he managed to convince me that there is an even better way > that we could do this. > > It's really quite elegant. Let's hear more. Especially if we can get efficient access to thread-specific data. I've been looking at various papers on threading, and was the most impressed with the "Scheduler Activations: Effective Kernel Support for the User Level Management of Parallelism". The basic plan I had laid out was to: 1. Develop support for {get,set,make,swap}context. 2. Add a system call or two to allow the kernel to upcall to a ucontext which would notify the threads library when a process blocks/unblocks in the kernel. This would also change the threads library and eliminate all the polling. 3. Add support for multiple [lightweight] processes to get M by N threading. The basic problem here is how to get fast access to thread-specific data (including a pointer to the current thread). I have working i386 support for 1. Marcel said he might be able to help with the Alpha-bits. #2 doesn't seem that difficult, but will involve changes to the wait queues that might be questioned. My biggest concern with #3 was TSD. Inter [lightweight] process locking doesn't seem _that_ difficult given that the threads library does all the scheduling and is notified when a process blocks. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 13:26:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 04BE614D8C for ; Thu, 28 Oct 1999 13:26:34 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA02745 for ; Thu, 28 Oct 1999 22:26:32 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA34825 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 22:26:32 +0200 (MET DST) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 806ED153A0 for ; Thu, 28 Oct 1999 13:26:01 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (ind.alcatel.com 2.3 [OUT])) id NAA02509; Thu, 28 Oct 1999 13:23:43 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id NAA12986; Thu, 28 Oct 1999 13:23:43 -0700 Received: from softweyr.com (dyn7.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA28497; Thu, 28 Oct 99 13:23:30 PDT Message-Id: <3818B0CB.6096CF3@softweyr.com> Date: Thu, 28 Oct 1999 14:23:39 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: "Daniel O'Connor" Cc: Warner Losh , Christopher Masto , freebsd-arch@freebsd.org Subject: Re: Racing interrupts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel O'Connor wrote: > > On 28-Oct-99 Warner Losh wrote: > > : Hmm.. Well.. Does this happen in PAO? > > : ie if I tell it to power off the card does it DTRT? > > Yes. And -current did the right thing until I broke it recently. > > Ahh.. > Still.. I sense the potential for a doc app for window maker here :) An excellent idea. A PCCard/CardBus mangler dockapp would be great. -- "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 Thu Oct 28 15:41: 3 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 995C614C39 for ; Thu, 28 Oct 1999 15:41:00 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA04258 for ; Fri, 29 Oct 1999 00:40:59 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA35488 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 00:40:57 +0200 (MET DST) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 3799E14C39 for ; Thu, 28 Oct 1999 15:40:46 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40336>; Fri, 29 Oct 1999 08:35:37 +1000 Content-return: prohibited Date: Fri, 29 Oct 1999 08:40:38 +1000 From: Peter Jeremy Subject: Re: Storing small files in inodes In-reply-to: <199910281926.MAA25987@kithrup.com> To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct29.083537est.40336@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <99Oct28.135145est.40328@border.alcanet.com.au> <3.0.6.32.19991028081210.0079b7a0.kithrup.freebsd.freebsd-arch@192.168.255.1> <199910281926.MAA25987@kithrup.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-29 05:26:40 +1000, Sean Eric Fagan wrote: >And we're _already_ doing it for a particular class of files -- symlinks. Though symlinks are much easier to handle - you can only create them, read them and delete them. You can't update or mmap them. > My >only concern is that I'd like an option to disable it on a per-filesystem >basis. I suspect this would have to be a newfs option. To be able to use tunefs to enable/disable it would imply supporting both types of files within the same filesystem - which further implies a bit in the inode, or relying on the content of di_blocks. I believe we would need a new format (FS_??INODEFMT) in fs_inodefmt, which indicates that that all short files are stored in the inode. The length of the files could be indicated either by overloading (and possibly renaming) fs_maxsymlinklen or adding a new `fs_maxshortfile' which represents the same value as fs_maxsymlinklen. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 15:56:33 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E0ED414DA5 for ; Thu, 28 Oct 1999 15:56:29 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA04381 for ; Fri, 29 Oct 1999 00:56:28 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA35566 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 00:56:28 +0200 (MET DST) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 8FA7815125 for ; Thu, 28 Oct 1999 15:56:04 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40332>; Fri, 29 Oct 1999 08:50:56 +1000 Content-return: prohibited Date: Fri, 29 Oct 1999 08:55:57 +1000 From: Peter Jeremy Subject: Re: Storing small files in inodes In-reply-to: To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct29.085056est.40332@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <99Oct28.135145est.40328@border.alcanet.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-28 19:33:22 +1000, Julian Elischer wrote: >we'd have the code to read it turned on by default for 6 months before we >turned on the default to write them. This is fairly messy. I see them implemented as a new FS format. In which case the schedule would be: - update fsck(8), fsdb(8), dump(8), libstand/ufs.c and the kernel to know how to handle the new FS format. fsck should also gain the ability to convert FS_44INODEFMT to the new format and dumpfs(8) to report the new format. - update newfs(8) to be able to create an FS in the new format (ie a different constant in fs_inodefmt), but still default to FS_44INODEFMT - remind everyone to update their bootblocks before converting their root FS - wait a few releases (6-12 months) - update newfs(8) to default to the new FS format. You would still need to manually convert existing filesystems - either by dump/newfs/restore or 'fsck -c 4'. >I vaguely remember a paper on the topic. I was sure I wasn't the first one to think of this. >Maybe kirk can tell us more. I was hoping that some of the FS gurus would comment. They would have a much better feeling for the complexity of the changes - I have a nasty suspicion that the code to handle a file growing from 60 to 61 bytes (or vice versa) and mmap'ing a short file would be non-trivial. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 18:30:33 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 902F214EEC for ; Thu, 28 Oct 1999 18:30:19 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA13009 for ; Fri, 29 Oct 1999 03:30:16 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA36194 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 03:30:15 +0200 (MET DST) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 699E914BCF for ; Thu, 28 Oct 1999 18:29:18 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id KAA05289; Fri, 29 Oct 1999 10:58:57 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199910281916.NAA29823@mt.sri.com> Date: Fri, 29 Oct 1999 10:58:57 +0930 (CST) From: "Daniel O'Connor" To: Nate Williams Subject: Re: rfork patch, please comment Cc: freebsd-arch@freebsd.org, Marcel Moolenaar , Jake Burkholder , Julian Elischer Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 28-Oct-99 Nate Williams wrote: > > other day and he managed to convince me that there is an even better way > > that we could do this. > > It's really quite elegant. > And that elegant solution would be.........??? And the next question is.. How long would this elegant solution take to appear? :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 21:43:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 891AB14CE0 for ; Thu, 28 Oct 1999 21:43:42 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA15560 for ; Fri, 29 Oct 1999 06:43:41 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA36762 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 06:43:41 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 89B37155F2 for ; Thu, 28 Oct 1999 21:42:01 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id VAA58569; Thu, 28 Oct 1999 21:41:51 -0700 (PDT) Date: Thu, 28 Oct 1999 21:41:51 -0700 (PDT) From: Julian Elischer To: "Daniel O'Connor" Cc: Nate Williams , freebsd-arch@freebsd.org, Marcel Moolenaar , Jake Burkholder Subject: Re: rfork patch, please comment 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 Actually the kernel side of it would be quite quick.. there is a user side component that multiplexes the user threads onto the kernel threads but it's actually pretty straight forward. We may try give a bit of a talk about it a t teh next Bay Area freeBS User's Group meeting.. As well as dicuss the other possibilities. That'll give us a reason to get our act together. :-) On Fri, 29 Oct 1999, Daniel O'Connor wrote: > > On 28-Oct-99 Nate Williams wrote: > > > other day and he managed to convince me that there is an even better way > > > that we could do this. > > > It's really quite elegant. > > And that elegant solution would be.........??? > > And the next question is.. How long would this elegant solution take to appear? > :) > > --- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 21:47: 2 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 579B514C20 for ; Thu, 28 Oct 1999 21:46:59 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA15582 for ; Fri, 29 Oct 1999 06:46:59 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA36788 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 06:46:59 +0200 (MET DST) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id E035914C20 for ; Thu, 28 Oct 1999 21:46:49 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id OAA08283; Fri, 29 Oct 1999 14:16:30 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 29 Oct 1999 14:16:29 +0930 (CST) From: "Daniel O'Connor" To: Julian Elischer Subject: Re: rfork patch, please comment Cc: Jake Burkholder , Marcel Moolenaar , freebsd-arch@freebsd.org, Nate Williams Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 29-Oct-99 Julian Elischer wrote: > Actually the kernel side of it would be quite quick.. > there is a user side component that multiplexes the user threads onto the > kernel threads but it's actually pretty straight forward. Wel I meant how long it would take to appear.. It seems a shame to throw away someones hard work. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 21:50:32 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id EFD9614C20 for ; Thu, 28 Oct 1999 21:50:29 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA15609 for ; Fri, 29 Oct 1999 06:50:28 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA36818 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 06:50:28 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 376E014C20 for ; Thu, 28 Oct 1999 21:50:22 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id WAA04837; Thu, 28 Oct 1999 22:50:09 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id WAA02527; Thu, 28 Oct 1999 22:50:05 -0600 Date: Thu, 28 Oct 1999 22:50:05 -0600 Message-Id: <199910290450.WAA02527@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: "Daniel O'Connor" , Nate Williams , freebsd-arch@freebsd.org, Marcel Moolenaar , Jake Burkholder Subject: Re: rfork patch, please comment In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Actually the kernel side of it would be quite quick.. > there is a user side component that multiplexes the user threads onto the > kernel threads but it's actually pretty straight forward. > > We may try give a bit of a talk about it a t teh next Bay Area freeBS > User's Group meeting.. As well as dicuss the other possibilities. > That'll give us a reason to get our act together. :-) Except that 99% of the FreeBSD developers don't got the the User's group meeting in the Bay Area. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 28 22:59:57 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2C6C314D1B for ; Thu, 28 Oct 1999 22:59:54 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA16185 for ; Fri, 29 Oct 1999 07:59:53 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA37108 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 07:59:53 +0200 (MET DST) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 6491E14D1B for ; Thu, 28 Oct 1999 22:59:47 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11h54k-0005Mu-00; Thu, 28 Oct 1999 23:59:46 -0600 Message-ID: <381937D0.BD15D2E5@softweyr.com> Date: Thu, 28 Oct 1999 23:59:44 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: rfork patch, please comment References: <199910290450.WAA02527@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > > Actually the kernel side of it would be quite quick.. > > there is a user side component that multiplexes the user threads onto the > > kernel threads but it's actually pretty straight forward. > > > > We may try give a bit of a talk about it a t teh next Bay Area freeBS > > User's Group meeting.. As well as dicuss the other possibilities. > > That'll give us a reason to get our act together. :-) > > Except that 99% of the FreeBSD developers don't got the the User's group > meeting in the Bay Area. Unless that is Farmington Bay. ;^) -- "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 Thu Oct 28 23: 3:16 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CB9BB1508E for ; Thu, 28 Oct 1999 23:03:14 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA16232 for ; Fri, 29 Oct 1999 08:03:13 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA37142 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 08:03:13 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 7257714D1B for ; Thu, 28 Oct 1999 23:03:05 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id XAA59880; Thu, 28 Oct 1999 23:02:58 -0700 (PDT) Date: Thu, 28 Oct 1999 23:02:58 -0700 (PDT) From: Julian Elischer To: Nate Williams Cc: "Daniel O'Connor" , freebsd-arch@freebsd.org, Marcel Moolenaar , Jake Burkholder Subject: Re: rfork patch, please comment In-Reply-To: <199910290450.WAA02527@mt.sri.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 but it will give us the inputus to produce something actually written down. On Thu, 28 Oct 1999, Nate Williams wrote: > > Actually the kernel side of it would be quite quick.. > > there is a user side component that multiplexes the user threads onto the > > kernel threads but it's actually pretty straight forward. > > > > We may try give a bit of a talk about it a t teh next Bay Area freeBS > > User's Group meeting.. As well as dicuss the other possibilities. > > That'll give us a reason to get our act together. :-) > > Except that 99% of the FreeBSD developers don't got the the User's group > meeting in the Bay Area. > > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 2:36:12 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7976415094 for ; Fri, 29 Oct 1999 02:36:06 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA19646 for ; Fri, 29 Oct 1999 11:36:04 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA37666 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 11:36:02 +0200 (MET DST) Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id B2BC41509B for ; Fri, 29 Oct 1999 02:35:48 -0700 (PDT) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.02 #1) id 11h8RX-0002Jk-00; Fri, 29 Oct 1999 09:35:31 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id LAA37376; Fri, 29 Oct 1999 11:35:24 +0200 (CEST) (envelope-from marcel@scc.nl) Message-ID: <38196A5C.F4354C66@scc.nl> Date: Fri, 29 Oct 1999 11:35:24 +0200 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Nate Williams , "Daniel O'Connor" , freebsd-arch@freebsd.org, Jake Burkholder Subject: Re: rfork patch, please comment References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > but it will give us the inputus to produce something actually written > down. > > On Thu, 28 Oct 1999, Nate Williams wrote: > > > > Actually the kernel side of it would be quite quick.. > > > there is a user side component that multiplexes the user threads onto the > > > kernel threads but it's actually pretty straight forward. > > > > > > We may try give a bit of a talk about it a t teh next Bay Area freeBS > > > User's Group meeting.. As well as dicuss the other possibilities. > > > That'll give us a reason to get our act together. :-) > > > > Except that 99% of the FreeBSD developers don't got the the User's group > > meeting in the Bay Area. Either discuss Jake's work, or discuss the "elegant" solution in detail. There's no point in being vague and off topic at the same time :-) -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 2:52:11 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2CA4114D0B for ; Fri, 29 Oct 1999 02:52:04 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA19860 for ; Fri, 29 Oct 1999 11:52:02 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA37713 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 11:52:01 +0200 (MET DST) Received: from friley-160-236.res.iastate.edu (friley-160-236.res.iastate.edu [129.186.160.236]) by hub.freebsd.org (Postfix) with ESMTP id A6A5714D0B for ; Fri, 29 Oct 1999 02:51:48 -0700 (PDT) (envelope-from cc@137.org) Received: from ameslab.gov (friley-160-235.res.iastate.edu [129.186.160.235]) by friley-160-236.res.iastate.edu (Postfix) with ESMTP id E89F614A; Fri, 29 Oct 1999 04:51:46 -0500 (CDT) Message-ID: <38196E32.BD1F51CD@ameslab.gov> Date: Fri, 29 Oct 1999 04:51:46 -0500 From: Chris Csanady X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en, ru, ja, ko MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: rfork patch, please comment References: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > I know I've been a fan of using rfork for native threads, > (and all the support that we need for a linuxthreads is already there > (see the linuxthread PORT to freebsd)). But I was speakin gwith terry the > other day and he managed to convince me that there is an even better way > that we could do this. > > It's really quite elegant. Were you reffering to the use of async call gates, in conjunction with a user space call conversion scheduler? I have read many of Terry's posts regarding this type of thing, and it seems quite brilliant. Honestly, I would be quite disappointed if we went with a threading solution such as linux provides. (Or any of the other typical solutions.) Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 3:16:14 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2892614CF7 for ; Fri, 29 Oct 1999 03:16:11 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA20230 for ; Fri, 29 Oct 1999 12:16:10 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA37841 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 12:16:10 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 4C9AA15506 for ; Fri, 29 Oct 1999 03:15:49 -0700 (PDT) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id DAA64016; Fri, 29 Oct 1999 03:15:47 -0700 (PDT) Date: Fri, 29 Oct 1999 03:15:46 -0700 (PDT) From: Julian Elischer X-Sender: julian@home.elischer.org To: Chris Csanady Cc: freebsd-arch@freebsd.org Subject: Re: rfork patch, please comment In-Reply-To: <38196E32.BD1F51CD@ameslab.gov> 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 yes that's the one.. it's easier to understand when you have the diagrams and he's here explaining them.. On Fri, 29 Oct 1999, Chris Csanady wrote: > Julian Elischer wrote: > > > > I know I've been a fan of using rfork for native threads, > > (and all the support that we need for a linuxthreads is already there > > (see the linuxthread PORT to freebsd)). But I was speakin gwith terry the > > other day and he managed to convince me that there is an even better way > > that we could do this. > > > > It's really quite elegant. > > Were you reffering to the use of async call gates, in conjunction with a > user space call conversion scheduler? > > I have read many of Terry's posts regarding this type of thing, and it > seems quite brilliant. Honestly, I would be quite disappointed if we > went with a threading solution such as linux provides. (Or any of the > other typical solutions.) > > Chris > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 4:55:58 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 21EF215584 for ; Fri, 29 Oct 1999 04:55:54 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA21884 for ; Fri, 29 Oct 1999 13:55:51 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA38339 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 13:55:51 +0200 (MET DST) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 91F2915584 for ; Fri, 29 Oct 1999 04:55:39 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA10817; Fri, 29 Oct 1999 07:54:13 -0400 (EDT) Date: Fri, 29 Oct 1999 07:54:13 -0400 (EDT) From: Daniel Eischen Message-Id: <199910291154.HAA10817@pcnet1.pcnet.com> To: cc@137.org, julian@whistle.com Subject: Re: rfork patch, please comment Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > yes that's the one.. > it's easier to understand when you have the diagrams and he's here > explaining them.. > > On Fri, 29 Oct 1999, Chris Csanady wrote: > [...] > > Were you reffering to the use of async call gates, in conjunction with a > > user space call conversion scheduler? Can you put the diagrams up for others to see? I really think the "Scheduler Activations" paper is worth a read if you haven't already. It's available at acm.org, but reading the fine print, I think I can put it on freefall as long as it's not for direct commercial advantage. You can grab it from: http://www.freebsd.org/~deischen/p95-anderson.pdf The async call gates and user space call conversion scheduler sounds similar to scheduler activations, but I think the difference is that for async call gates, the kernel creates an kernel thread to assist a potentially blocking system call, whereas scheduler activations perform a context switch when a thread blocks in the kernel. I guess both methods would notify the user-level threads library of the event. Did I get that right? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 6:11:29 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E16691558E for ; Fri, 29 Oct 1999 06:11:23 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA23324 for ; Fri, 29 Oct 1999 15:11:20 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA38643 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 15:11:19 +0200 (MET DST) Received: from hda.hda.com (hda.bicnet.net [208.220.68.243]) by hub.freebsd.org (Postfix) with ESMTP id 1E0D414FDF for ; Fri, 29 Oct 1999 06:11:07 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id JAA06778 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 09:06:07 -0400 (EDT) From: Peter Dufault Message-Id: <199910291306.JAA06778@hda.hda.com> Subject: Scheduler fixes To: freebsd-arch@freebsd.org Date: Fri, 29 Oct 1999 09:06:06 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL25 (25)] 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 put scheduler patches up on Freefall for review. They're in PATCHES.scheduler. Ignore everything in the posix1b directories and just look at the sys/kern and sys/{i386,alpha} changes. This doesn't directly address the recent alpha complaints yet, it is just a revisit to the scheduler to get back up to speed. I've also added "synch.9" to talk about what is in there. In particular look at hoisting userret into machine indepedent. I looked at 4.4Lite and I believe multiple arches can still be supported cleanly while moving a lot of this stuff into mi code, maybe at the cost of some per-arch "methods" passed in. Note that I've changed the kernel priority level on the Alpha of userret to splhigh - everything else is being done in the scheduler code at splhigh and that was pretty much the only difference between alpha and i386 (other than i386 previously being inline). Note - I nuked my new "sys/sys/synch.h" header when creating patches, so I quickly recreated it this morning and verified the kernel still builds. If you notice anything funky about the headers that is why. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 8: 2:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8FA8014BF7 for ; Fri, 29 Oct 1999 08:02:36 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA25136 for ; Fri, 29 Oct 1999 17:02:35 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA39265 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 17:02:34 +0200 (MET DST) Received: by hub.freebsd.org (Postfix, from userid 608) id BB45314BF7; Fri, 29 Oct 1999 08:02:28 -0700 (PDT) From: "Jonathan M. Bresler" To: peter.jeremy@alcatel.com.au Cc: freebsd-arch@freebsd.org In-reply-to: <99Oct29.085056est.40332@border.alcanet.com.au> (message from Peter Jeremy on Fri, 29 Oct 1999 08:55:57 +1000) Subject: Re: Storing small files in inodes Message-Id: <19991029150228.BB45314BF7@hub.freebsd.org> Date: Fri, 29 Oct 1999 08:02:28 -0700 (PDT) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >I vaguely remember a paper on the topic. > I was sure I wasn't the first one to think of this. > http://www.usenix.org/publications/library/proceedings/ana97/ganger.html With embedded inodes, the inodes for most files are stored in the directory with the corresponding name, removing a physical level of indirection without sacrificing the logical level of indirection. With explicit grouping, the data blocks of multiple small files named by a given directory are allocated adjacently and moved to and from the disk as a unit in most cases. Measurement for our C-FSS implementation show that embedded inodes and explicit grouping have the potential to increase small file throughput (for both reads and writes) by a factor of 5-7 compared to the same file system without these techniques. The improvement comes directly from reducing the number of disk accesses required by an order of magnitude. Preliminary experience with software-development applications shows performance improvements ranging from 30-300 percent. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 8:43:40 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 214E815056 for ; Fri, 29 Oct 1999 08:43:36 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA25607 for ; Fri, 29 Oct 1999 17:43:35 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA39387 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 17:43:34 +0200 (MET DST) Received: from bachue.usc.unal.edu.co (bachue.usc.unal.edu.co [168.176.3.20]) by hub.freebsd.org (Postfix) with ESMTP id A658D150B1 for ; Fri, 29 Oct 1999 08:40:03 -0700 (PDT) (envelope-from pfgiffun@bachue.usc.unal.edu.co) Received: from bachue.usc.unal.edu.co ([168.176.3.53]) by bachue.usc.unal.edu.co (Netscape Messaging Server 3.6) with ESMTP id AAA2A69 for ; Fri, 29 Oct 1999 10:39:33 -0400 Message-ID: <3819C1D9.FA1C3D58@bachue.usc.unal.edu.co> Date: Fri, 29 Oct 1999 10:48:41 -0500 From: "Pedro Fernando Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: Storing small files in inodes References: <19991029150228.BB45314BF7@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The code for this is available as part of MIT's exokernel, and there was someone (csapuntz?) porting it to OpenBSD. cheers, Pedro. "Jonathan M. Bresler" wrote: > ... > > http://www.usenix.org/publications/library/proceedings/ana97/ganger.html > > With embedded inodes, the inodes for most files are stored in the > directory with the corresponding name, removing a physical level of > indirection without sacrificing the logical level of indirection. With > explicit grouping, the data blocks of multiple small files named by a > given directory are allocated adjacently and moved to and from the > disk as a unit in most cases. Measurement for our C-FSS implementation > show that embedded inodes and explicit grouping have the potential to > increase small file throughput (for both reads and writes) by a factor > of 5-7 compared to the same file system without these techniques. The > improvement comes directly from reducing the number of disk accesses > required by an order of magnitude. Preliminary experience > with software-development applications shows performance improvements > ranging from 30-300 percent. > > jmb > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 9:57:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 10C0314E7E for ; Fri, 29 Oct 1999 09:57:34 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA26561 for ; Fri, 29 Oct 1999 18:57:31 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA39832 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 18:57:29 +0200 (MET DST) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id E4934152DC for ; Fri, 29 Oct 1999 09:57:17 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id JAA09814; Fri, 29 Oct 1999 09:56:40 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpdAAAuFaqht; Fri Oct 29 09:56:32 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id JAA15890; Fri, 29 Oct 1999 09:56:56 -0700 (MST) From: Terry Lambert Message-Id: <199910291656.JAA15890@usr02.primenet.com> Subject: Re: Racing interrupts To: nate@mt.sri.com Date: Fri, 29 Oct 1999 16:56:56 +0000 (GMT) Cc: tlambert@primenet.com, rjesup@wgate.com, imp@village.org, arch@freebsd.org In-Reply-To: <199910270204.UAA21334@mt.sri.com> from "Nate Williams" at Oct 26, 99 08:04:20 pm X-Mailer: ELM [version 2.4 PL25] 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'd like to get agreed that it's possible to work around the crappy > > hardware, to get a roadmap laid down, even if there isn't currently > > code. > > Much of *code* that you are are screaming for *EXISTS* in FreeBSD today, > and guess what, it doesn't work very well, because of all the problems > I've pointed out. > > I wrote the code, so there's no need for roadmaps and/or long > discussions about the merits of it. The basic problem that Warner was > discussing is a 'fact of life', and fixing it to never occur is simply > not possible, and making it better than it already is implies a huge > overhead. I don't believe in impossible, and I don't care about overhead if something is worth doing. 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 Fri Oct 29 11: 9:14 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 124E41550E for ; Fri, 29 Oct 1999 11:09:09 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA27175 for ; Fri, 29 Oct 1999 20:09:08 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA40186 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 20:09:02 +0200 (MET DST) Received: from bachue.usc.unal.edu.co (bachue.usc.unal.edu.co [168.176.3.20]) by hub.freebsd.org (Postfix) with ESMTP id E12181551C for ; Fri, 29 Oct 1999 11:04:32 -0700 (PDT) (envelope-from pfgiffun@bachue.usc.unal.edu.co) Received: from bachue.usc.unal.edu.co ([168.176.3.36]) by bachue.usc.unal.edu.co (Netscape Messaging Server 3.6) with ESMTP id AAA2C47 for ; Fri, 29 Oct 1999 13:04:03 -0400 Message-ID: <3819E3C2.B4958AC6@bachue.usc.unal.edu.co> Date: Fri, 29 Oct 1999 13:13:22 -0500 From: "Pedro Fernando Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: Storing small files in inodes References: <19991029150228.BB45314BF7@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I found some free references for those of us not on USENIX: http://amsterdam.lcs.mit.edu/papers/cffs.html http://www.pdos.lcs.mit.edu/papers/exo-sosp97/exo-sosp97.html The Exokernel and Logical Disks links are interesting: http://www.pdos.lcs.mit.edu/ enjoy, Pedro. "Jonathan M. Bresler" wrote: > > > > > >I vaguely remember a paper on the topic. > > I was sure I wasn't the first one to think of this. > > > > http://www.usenix.org/publications/library/proceedings/ana97/ganger.html > > With embedded inodes, the inodes for most files are stored in the > directory with the corresponding name, removing a physical level of > indirection without sacrificing the logical level of indirection. With > explicit grouping, the data blocks of multiple small files named by a > given directory are allocated adjacently and moved to and from the > disk as a unit in most cases. Measurement for our C-FSS implementation > show that embedded inodes and explicit grouping have the potential to > increase small file throughput (for both reads and writes) by a factor > of 5-7 compared to the same file system without these techniques. The > improvement comes directly from reducing the number of disk accesses > required by an order of magnitude. Preliminary experience > with software-development applications shows performance improvements > ranging from 30-300 percent. > > jmb > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 11:14:12 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 591EF14FF2 for ; Fri, 29 Oct 1999 11:14:07 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA27246 for ; Fri, 29 Oct 1999 20:14:06 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA40261 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 20:14:05 +0200 (MET DST) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id BC2CB14FF2 for ; Fri, 29 Oct 1999 11:13:57 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id LAA28007 for ; Fri, 29 Oct 1999 11:13:52 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id LAA87986 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 11:13:52 -0700 (PDT) (envelope-from obrien) Date: Fri, 29 Oct 1999 11:13:52 -0700 From: "David O'Brien" To: freebsd-arch@freebsd.org Subject: stpcpy() Message-ID: <19991029111352.A87934@dragon.nuxi.com> Reply-To: obrien@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG More and more GNU (and other GPV) software is starting to use the Linuxism known as stpcpy(). stpcpy() is effectively: p = strcpy(d,s); p += strlen(d); I'm considering adding stpcpy() to libc. Comments? -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 11:22:22 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 33B92154FC for ; Fri, 29 Oct 1999 11:22:05 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA27315 for ; Fri, 29 Oct 1999 20:22:04 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA40319 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 20:22:04 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7F5301557C; Fri, 29 Oct 1999 11:20:15 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA49683; Fri, 29 Oct 1999 12:20:14 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA89334; Fri, 29 Oct 1999 12:21:48 -0600 (MDT) Message-Id: <199910291821.MAA89334@harmony.village.org> To: obrien@freebsd.org Subject: Re: stpcpy() Cc: freebsd-arch@freebsd.org In-reply-to: Your message of "Fri, 29 Oct 1999 11:13:52 PDT." <19991029111352.A87934@dragon.nuxi.com> References: <19991029111352.A87934@dragon.nuxi.com> Date: Fri, 29 Oct 1999 12:21:48 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19991029111352.A87934@dragon.nuxi.com> "David O'Brien" writes: : More and more GNU (and other GPV) software is starting to use the : Linuxism known as stpcpy(). stpcpy() is effectively: : : p = strcpy(d,s); : p += strlen(d); : : I'm considering adding stpcpy() to libc. Comments? stpcpy() is non standard. It falls outside of the namespace reserved by the standard. You should be careful to ensure that it is only defined when we aren't in strict standard conforming mode. Since it falls outside of the namespace reserved by the standards, I'd be less inclined to include it w/o making sure it is a weak symbol. The strl* routines I added are part of the reserved name space of ANSI-C (and children) since all routines beginning with str* are reserved to the committee, so I didn't have to be horribly careful since I wouldn't be breaking standard conforming programs. Since adding stpcpy might do that, we should make sure that all uses of it have the same semantic meaning, including the ports tree, and change those instances of it where this isn't the case. I would have concerns about merging into -stable, but I believe most of them are answered by making the symbol weak. This is a long way of saying that I support this, assuming that you are careful :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 11:23:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CB84414FF2 for ; Fri, 29 Oct 1999 11:23:50 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA27334 for ; Fri, 29 Oct 1999 20:23:31 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA40346 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 20:23:31 +0200 (MET DST) Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id 4CE2D154BA; Fri, 29 Oct 1999 11:22:02 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org ([216.62.157.60]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FKD00JZ8N0NMA@mta4.rcsntx.swbell.net>; Fri, 29 Oct 1999 13:21:59 -0500 (CDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id NAA00562; Fri, 29 Oct 1999 13:22:58 -0500 (CDT envelope-from chris) X-URL: http://www.FreeBSD.org/~chris/ Date: Fri, 29 Oct 1999 13:22:57 -0500 From: Chris Costello Subject: Re: stpcpy() In-reply-to: <19991029111352.A87934@dragon.nuxi.com> To: obrien@freebsd.org Cc: freebsd-arch@freebsd.org Reply-To: chris@calldei.com Message-id: <19991029132257.A535@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i X-Operating-System: FreeBSD 4.0-CURRENT (i386) References: <19991029111352.A87934@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 29, 1999, David O'Brien wrote: > More and more GNU (and other GPV) software is starting to use the > Linuxism known as stpcpy(). stpcpy() is effectively: > > p = strcpy(d,s); > p += strlen(d); > > I'm considering adding stpcpy() to libc. Comments? I'm seeing more and more of a need for a compat library for Linux and GNU software in general. Adding unnecessary bloat to our libc isn't necessary, in my opinion. -- |Chris Costello |Abstraction is achieved by data hiding and enforced by encapsulation. `--------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 11:28:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 40F501554A for ; Fri, 29 Oct 1999 11:28:44 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA27380 for ; Fri, 29 Oct 1999 20:28:43 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA40380 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 20:28:38 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 8DD3B155E5; Fri, 29 Oct 1999 11:28:05 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA49714; Fri, 29 Oct 1999 12:28:04 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA89401; Fri, 29 Oct 1999 12:29:38 -0600 (MDT) Message-Id: <199910291829.MAA89401@harmony.village.org> To: chris@calldei.com Subject: Re: stpcpy() Cc: obrien@freebsd.org, freebsd-arch@freebsd.org In-reply-to: Your message of "Fri, 29 Oct 1999 13:22:57 CDT." <19991029132257.A535@holly.calldei.com> References: <19991029132257.A535@holly.calldei.com> <19991029111352.A87934@dragon.nuxi.com> Date: Fri, 29 Oct 1999 12:29:38 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19991029132257.A535@holly.calldei.com> Chris Costello writes: : I'm seeing more and more of a need for a compat library for : Linux and GNU software in general. Adding unnecessary bloat to : our libc isn't necessary, in my opinion. The problem with this is that it becomes harder to build on FreeBSD because you have to add additional, non-standard libraries to the build process. This is the fault of the author of the tool, since they used non-standard interfaces, so maybe it wouldn't be too bad. The risk we run in not supporting them in libc is the perception that FreeBSD isn't compatible (never mind what the sstandards say). We have similar issues with the long getopt stuff. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 11:45:34 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 796881551C for ; Fri, 29 Oct 1999 11:45:19 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA27530 for ; Fri, 29 Oct 1999 20:45:15 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA40455 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 20:45:09 +0200 (MET DST) Received: from mta2.rcsntx.swbell.net (mta2.rcsntx.swbell.net [151.164.30.26]) by hub.freebsd.org (Postfix) with ESMTP id BCE1E1551C; Fri, 29 Oct 1999 11:44:55 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org ([216.62.157.60]) by mta2.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FKD006CCO2Q3P@mta2.rcsntx.swbell.net>; Fri, 29 Oct 1999 13:44:51 -0500 (CDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id NAA00655; Fri, 29 Oct 1999 13:45:50 -0500 (CDT envelope-from chris) X-URL: http://www.FreeBSD.org/~chris/ Date: Fri, 29 Oct 1999 13:45:49 -0500 From: Chris Costello Subject: Re: stpcpy() In-reply-to: <199910291829.MAA89401@harmony.village.org> To: Warner Losh Cc: obrien@freebsd.org, freebsd-arch@freebsd.org Reply-To: chris@calldei.com Message-id: <19991029134549.B535@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i X-Operating-System: FreeBSD 4.0-CURRENT (i386) References: <19991029132257.A535@holly.calldei.com> <19991029111352.A87934@dragon.nuxi.com> <19991029132257.A535@holly.calldei.com> <199910291829.MAA89401@harmony.village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 29, 1999, Warner Losh wrote: > In message <19991029132257.A535@holly.calldei.com> Chris Costello writes: > : I'm seeing more and more of a need for a compat library for > : Linux and GNU software in general. Adding unnecessary bloat to > : our libc isn't necessary, in my opinion. > > The problem with this is that it becomes harder to build on FreeBSD > because you have to add additional, non-standard libraries to the > build process. This is the fault of the author of the tool, since > they used non-standard interfaces, so maybe it wouldn't be too bad. > The risk we run in not supporting them in libc is the perception that > FreeBSD isn't compatible (never mind what the sstandards say). That's the problem. I honestly can't begin to think of a perfect way of getting around Linux developers putting kludge after kludge on top of poorly written workarounds on top of hacks that were never really fully implemented (as far as libc goes). Put their functions in our libc and we end up with a bigger, bloated libc. Make a new library and cause trouble for people wanting to build the latest greatest Linux program on FreeBSD. -- |Chris Costello |Your fault, core dumped. `---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 11:52: 9 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 407CF152D6 for ; Fri, 29 Oct 1999 11:52:06 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA27600 for ; Fri, 29 Oct 1999 20:52:05 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA40513 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 20:52:04 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 3CC211551C for ; Fri, 29 Oct 1999 11:51:55 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id MAA11695; Fri, 29 Oct 1999 12:51:43 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA05434; Fri, 29 Oct 1999 12:51:41 -0600 Date: Fri, 29 Oct 1999 12:51:41 -0600 Message-Id: <199910291851.MAA05434@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com, rjesup@wgate.com, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910291656.JAA15890@usr02.primenet.com> References: <199910270204.UAA21334@mt.sri.com> <199910291656.JAA15890@usr02.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I don't believe in impossible OK, I want to fly w/out use of external devices. Oh, you mean with software? I want my computer to run 100X faster than it does now, w/out changing any of the hardware! > and I don't care about overhead if something is worth doing. Cool. I want you to start using my new compressed FS, which allows you to store 3X as much data on your hard disk. Unfortunately, the overhead of compressing/decompressing slows access to 1K/sec max., but it's worth doing, so the overhead is irrelevant. In other words, do you realize how silly you sound? nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 12: 6:10 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3D3BB15571 for ; Fri, 29 Oct 1999 12:06:04 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA27738 for ; Fri, 29 Oct 1999 21:06:03 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA40581 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 21:06:03 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id AEDC015571; Fri, 29 Oct 1999 12:03:58 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA11834; Fri, 29 Oct 1999 13:03:51 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA05546; Fri, 29 Oct 1999 13:03:50 -0600 Date: Fri, 29 Oct 1999 13:03:50 -0600 Message-Id: <199910291903.NAA05546@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: chris@calldei.com, obrien@freebsd.org, freebsd-arch@freebsd.org Subject: Re: stpcpy() In-Reply-To: <199910291829.MAA89401@harmony.village.org> References: <19991029132257.A535@holly.calldei.com> <19991029111352.A87934@dragon.nuxi.com> <199910291829.MAA89401@harmony.village.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : I'm seeing more and more of a need for a compat library for > : Linux and GNU software in general. Adding unnecessary bloat to > : our libc isn't necessary, in my opinion. > > The problem with this is that it becomes harder to build on FreeBSD Or Solaris, or SCO, or HP/UX, or Digital Unix, or *any* other OS besides Linux. Let's not encourage bad behavior by making FreeBSD also follow bad form.... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 13: 2:23 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BB00B14BD8 for ; Fri, 29 Oct 1999 13:02:18 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA28241 for ; Fri, 29 Oct 1999 22:02:17 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA40856 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 22:02:17 +0200 (MET DST) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 4B2E114BD8 for ; Fri, 29 Oct 1999 13:01:56 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id PAA11867 for ; Fri, 29 Oct 1999 15:56:55 -0400 (EDT) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Re: stpcpy() References: <19991029132257.A535@holly.calldei.com> <19991029111352.A87934@dragon.nuxi.com> <19991029132257.A535@holly.calldei.com> <199910291829.MAA89401@harmony.village.org> <19991029134549.B535@holly.calldei.com> From: Randell Jesup Date: 29 Oct 1999 15:58:14 +0000 In-Reply-To: Chris Costello's message of "Fri, 29 Oct 1999 13:45:49 -0500" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris Costello writes: >> : I'm seeing more and more of a need for a compat library for >> : Linux and GNU software in general. Adding unnecessary bloat to >> : our libc isn't necessary, in my opinion. >> >> The problem with this is that it becomes harder to build on FreeBSD >> because you have to add additional, non-standard libraries to the >> build process. > That's the problem. I honestly can't begin to think of a perfect >way of getting around Linux developers putting kludge after kludge >on top of poorly written workarounds on top of hacks that were never >really fully implemented (as far as libc goes). Put their >functions in our libc and we end up with a bigger, bloated libc. >Make a new library and cause trouble for people wanting to build >the latest greatest Linux program on FreeBSD. stpcpy() (the issue in this case) is something I've seen in compiler's C libraries since the late 80's/early 90's (if I remember correctly), if I remember correctly. Quite honestly, it's useful, and if the library mechanism/source is set up right, only affects programs that use it, and even then it's what, a dozen bytes or two (at most)? I remember writing my own version of it (before the Lattice compiler had it) in '85. It's handy and improves performance for the cases where it's used, and it's small. The only issue would be the fact that it's non-ANSI, but so are 5000 other things in the libraries (system calls, for example), and maybe that some application has it's own hard-coded version (thus someone's suggestion to use a weak symbol). IMHO. I'm not addressing the bigger issue of Linux compatibility. However, libc bloat doesn't seem to me to be a major problem - at worst a small amount of disk space, and a (very small) bit more CPU to link. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 13:13: 3 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B9F7415534 for ; Fri, 29 Oct 1999 13:13:01 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA28320 for ; Fri, 29 Oct 1999 22:13:00 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA40897 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 22:12:59 +0200 (MET DST) Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id D36921559A for ; Fri, 29 Oct 1999 13:12:32 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org ([216.62.157.60]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FKD00L2MS4J9S@mta4.rcsntx.swbell.net> for freebsd-arch@FreeBSD.ORG; Fri, 29 Oct 1999 15:12:20 -0500 (CDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id PAA01189; Fri, 29 Oct 1999 15:13:18 -0500 (CDT envelope-from chris) X-URL: http://www.FreeBSD.org/~chris/ Date: Fri, 29 Oct 1999 15:13:17 -0500 From: Chris Costello Subject: Re: stpcpy() In-reply-to: To: Randell Jesup Cc: freebsd-arch@freebsd.org Reply-To: chris@calldei.com Message-id: <19991029151317.E535@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i X-Operating-System: FreeBSD 4.0-CURRENT (i386) References: <19991029132257.A535@holly.calldei.com> <19991029111352.A87934@dragon.nuxi.com> <19991029132257.A535@holly.calldei.com> <199910291829.MAA89401@harmony.village.org> <19991029134549.B535@holly.calldei.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 29, 1999, Randell Jesup wrote: > stpcpy() (the issue in this case) is something I've seen in > compiler's C libraries since the late 80's/early 90's (if I remember > correctly), if I remember correctly. Quite honestly, it's useful, and > if the library mechanism/source is set up right, only affects programs > that use it, and even then it's what, a dozen bytes or two (at most)? > I remember writing my own version of it (before the Lattice compiler > had it) in '85. First it's stpcpy, then GNU getopt, then ... > It's handy and improves performance for the cases where it's > used, and it's small. The only issue would be the fact that it's > non-ANSI, but so are 5000 other things in the libraries (system calls, > for example), and maybe that some application has it's own hard-coded > version (thus someone's suggestion to use a weak symbol). IMHO. > > I'm not addressing the bigger issue of Linux compatibility. > However, libc bloat doesn't seem to me to be a major problem - at worst > a small amount of disk space, and a (very small) bit more CPU to link. The bigger issue of Linux compatibility is essentially what this is leading into. Currently the biggest users of stpcpy are Linux applications. Frankly it's hard enough at this point to deal with problems with the GNU getopt (awfully difficult to port programs using GNU getopt without replicating the getopt() code from glibc). At the same time, there are dozens of other Linux compatibility issues. Putting all these new foreign library calls into libc is not the solution unless we're interested in a larger library. The argument "hardware is cheap" is not valid. -- |Chris Costello |Never test for an error condition you don't |know how to handle. - Steinbach `------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 13:17:58 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8203014DA1 for ; Fri, 29 Oct 1999 13:17:49 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA28378 for ; Fri, 29 Oct 1999 22:17:48 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA40931 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 22:17:47 +0200 (MET DST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id AD23C14DA1 for ; Fri, 29 Oct 1999 13:17:37 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id WAA06168; Fri, 29 Oct 1999 22:16:16 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: chris@calldei.com Cc: Randell Jesup , freebsd-arch@freebsd.org Subject: Re: stpcpy() In-reply-to: Your message of "Fri, 29 Oct 1999 15:13:17 CDT." <19991029151317.E535@holly.calldei.com> Date: Fri, 29 Oct 1999 22:16:15 +0200 Message-ID: <6166.941228175@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19991029151317.E535@holly.calldei.com>, Chris Costello writes: > The bigger issue of Linux compatibility is essentially what >this is leading into. Currently the biggest users of stpcpy are >Linux applications. Frankly it's hard enough at this point to >deal with problems with the GNU getopt (awfully difficult to port >programs using GNU getopt without replicating the getopt() code >from glibc). At the same time, there are dozens of other Linux >compatibility issues. Putting all these new foreign library >calls into libc is not the solution unless we're interested in a >larger library. The argument "hardware is cheap" is not valid. Sounds to me like it's time to add these things to liblinuxcompat.a ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 13:20: 8 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C9FBB1558E for ; Fri, 29 Oct 1999 13:20:03 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA28408 for ; Fri, 29 Oct 1999 22:20:02 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA40956 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 22:20:02 +0200 (MET DST) Received: from mta2.rcsntx.swbell.net (mta2.rcsntx.swbell.net [151.164.30.26]) by hub.freebsd.org (Postfix) with ESMTP id 237EC14DA1 for ; Fri, 29 Oct 1999 13:19:55 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org ([216.62.157.60]) by mta2.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FKD00A2YSH21F@mta2.rcsntx.swbell.net> for freebsd-arch@FreeBSD.ORG; Fri, 29 Oct 1999 15:19:52 -0500 (CDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id PAA01257; Fri, 29 Oct 1999 15:20:50 -0500 (CDT envelope-from chris) X-URL: http://www.FreeBSD.org/~chris/ Date: Fri, 29 Oct 1999 15:20:49 -0500 From: Chris Costello Subject: liblinuxcompat (was Re: stpcpy()) In-reply-to: <6166.941228175@critter.freebsd.dk> To: Poul-Henning Kamp Cc: Randell Jesup , freebsd-arch@freebsd.org Reply-To: chris@calldei.com Message-id: <19991029152049.F535@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i X-Operating-System: FreeBSD 4.0-CURRENT (i386) References: <19991029151317.E535@holly.calldei.com> <6166.941228175@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 29, 1999, Poul-Henning Kamp wrote: > > The bigger issue of Linux compatibility is essentially what > >this is leading into. Currently the biggest users of stpcpy are > >Linux applications. Frankly it's hard enough at this point to > >deal with problems with the GNU getopt (awfully difficult to port > >programs using GNU getopt without replicating the getopt() code > >from glibc). At the same time, there are dozens of other Linux > >compatibility issues. Putting all these new foreign library > >calls into libc is not the solution unless we're interested in a > >larger library. The argument "hardware is cheap" is not valid. > > Sounds to me like it's time to add these things to liblinuxcompat.a ? I don't see any liblinuxcompat. Are you proposing that one should be created? -- |Chris Costello |There are two ways to write error-free programs; only the third one works. `-------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 13:48:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 14DF214C14 for ; Fri, 29 Oct 1999 13:48:31 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA28687 for ; Fri, 29 Oct 1999 22:48:30 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA41077 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 22:48:30 +0200 (MET DST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 0C41614C94 for ; Fri, 29 Oct 1999 13:48:12 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id WAA06367; Fri, 29 Oct 1999 22:46:46 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: chris@calldei.com Cc: Randell Jesup , freebsd-arch@freebsd.org Subject: Re: liblinuxcompat (was Re: stpcpy()) In-reply-to: Your message of "Fri, 29 Oct 1999 15:20:49 CDT." <19991029152049.F535@holly.calldei.com> Date: Fri, 29 Oct 1999 22:46:46 +0200 Message-ID: <6365.941230006@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19991029152049.F535@holly.calldei.com>, Chris Costello writes: >On Fri, Oct 29, 1999, Poul-Henning Kamp wrote: >> > The bigger issue of Linux compatibility is essentially what >> >this is leading into. Currently the biggest users of stpcpy are >> >Linux applications. Frankly it's hard enough at this point to >> >deal with problems with the GNU getopt (awfully difficult to port >> >programs using GNU getopt without replicating the getopt() code >> >from glibc). At the same time, there are dozens of other Linux >> >compatibility issues. Putting all these new foreign library >> >calls into libc is not the solution unless we're interested in a >> >larger library. The argument "hardware is cheap" is not valid. >> >> Sounds to me like it's time to add these things to liblinuxcompat.a ? > > I don't see any liblinuxcompat. Are you proposing that one >should be created? yes. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 14:22:32 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 903E4155A2 for ; Fri, 29 Oct 1999 14:22:23 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA28929 for ; Fri, 29 Oct 1999 23:22:19 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA41170 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 23:22:19 +0200 (MET DST) Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id F3AAA150EB for ; Fri, 29 Oct 1999 14:21:18 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id QAA14584; Fri, 29 Oct 1999 16:20:24 -0500 (CDT) Date: Fri, 29 Oct 1999 16:20:24 -0500 From: "Matthew D. Fuller" To: Poul-Henning Kamp Cc: chris@calldei.com, Randell Jesup , freebsd-arch@freebsd.org Subject: Re: liblinuxcompat (was Re: stpcpy()) Message-ID: <19991029162024.A4314@futuresouth.com> References: <19991029152049.F535@holly.calldei.com> <6365.941230006@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <6365.941230006@critter.freebsd.dk> X-OS: FreeBSD Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 29, 1999 at 10:46:46PM +0200, a little birdie told me that Poul-Henning Kamp remarked > In message <19991029152049.F535@holly.calldei.com>, Chris Costello writes: > >On Fri, Oct 29, 1999, Poul-Henning Kamp wrote: > >> > >> Sounds to me like it's time to add these things to liblinuxcompat.a ? > > > > I don't see any liblinuxcompat. Are you proposing that one > >should be created? > > yes. FWIW, I'm starting to agree. Of course, it should be named libinuxcompat, so you can link with -linuxcompat and look cool ;-> -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ FutureSouth Communications | ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 23: 1: 7 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6406F14F29 for ; Fri, 29 Oct 1999 23:01:04 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA04635 for ; Sat, 30 Oct 1999 08:00:59 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA45674 for freebsd-arch@freebsd.org; Sat, 30 Oct 1999 08:00:58 +0200 (MET DST) Received: from green.myip.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id EC1F614CB2 for ; Fri, 29 Oct 1999 23:00:49 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost ([127.0.0.1] ident=green) by green.myip.org with esmtp (Exim 3.02 #1) id 11hPDA-000LbU-00; Fri, 29 Oct 1999 23:29:49 -0400 Date: Fri, 29 Oct 1999 23:29:47 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.myip.org To: "Matthew D. Fuller" Cc: Poul-Henning Kamp , chris@calldei.com, Randell Jesup , freebsd-arch@freebsd.org Subject: Re: liblinuxcompat (was Re: stpcpy()) In-Reply-To: <19991029162024.A4314@futuresouth.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 For what it's worth, I'm pretty sure I proposed adding a glibc (originally would've been gnu in my mind :) subdir in src/lib/compat. As libcompat is quite small, I don't think this would be a bad thing to add. How about this? -- 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 Fri Oct 29 23:42:56 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 65C5614F66 for ; Fri, 29 Oct 1999 23:42:53 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA04965 for ; Sat, 30 Oct 1999 08:42:48 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA45803 for freebsd-arch@freebsd.org; Sat, 30 Oct 1999 08:42:48 +0200 (MET DST) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 6935B14FA0; Fri, 29 Oct 1999 23:42:34 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id XAA02520; Fri, 29 Oct 1999 23:42:33 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id XAA89622; Fri, 29 Oct 1999 23:42:33 -0700 (PDT) (envelope-from obrien) Date: Fri, 29 Oct 1999 23:42:33 -0700 From: "David O'Brien" To: Brian Fundakowski Feldman Cc: freebsd-arch@freebsd.org Subject: Re: liblinuxcompat (was Re: stpcpy()) Message-ID: <19991029234233.A89583@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <19991029162024.A4314@futuresouth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from green@freebsd.org on Fri, Oct 29, 1999 at 11:29:47PM -0400 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 29, 1999 at 11:29:47PM -0400, Brian Fundakowski Feldman wrote: > For what it's worth, I'm pretty sure I proposed adding a glibc (originally > would've been gnu in my mind :) subdir in src/lib/compat. lib/compat/ is not the place for it. Only binaries go there. I assume you were proposing a FreeBSD version of glibc, not Linux one. If we do it, it should live in src/contrib/glibc and install as /usr/lib/libglibc.* > As libcompat is quite small, I'd rather leave libcompat for BSD stuff. I'm already on the verge of creating /usr/lib/libiberty, so let me spend some more time thinking how to deal with the GNU/Linux'isms. (especially since I'm already the point man on enough stuff in src/contrib/ that is affected by such things. I've decided to not add stpcpy() to our libc. I could easily create a /usr/lib/libgnu.a (libfsf/liblinuxcompat/libwhatever) that is always linked against by GCC. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 29 23:47: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2450114F66 for ; Fri, 29 Oct 1999 23:47:02 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA05003 for ; Sat, 30 Oct 1999 08:47:01 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA45845 for freebsd-arch@freebsd.org; Sat, 30 Oct 1999 08:47:00 +0200 (MET DST) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 83E2814F66 for ; Fri, 29 Oct 1999 23:46:56 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id XAA02533; Fri, 29 Oct 1999 23:46:55 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id XAA89642; Fri, 29 Oct 1999 23:46:55 -0700 (PDT) (envelope-from obrien) Date: Fri, 29 Oct 1999 23:46:55 -0700 From: "David O'Brien" To: Randell Jesup Cc: freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <19991029234654.B89583@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <19991029132257.A535@holly.calldei.com> <19991029111352.A87934@dragon.nuxi.com> <19991029132257.A535@holly.calldei.com> <199910291829.MAA89401@harmony.village.org> <19991029134549.B535@holly.calldei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from rjesup@wgate.com on Fri, Oct 29, 1999 at 03:58:14PM +0000 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 29, 1999 at 03:58:14PM +0000, Randell Jesup wrote: > stpcpy() (the issue in this case) is something I've seen in > compiler's C libraries since the late 80's/early 90's (if I remember > correctly), if I remember correctly. Quite honestly, it's useful ... > It's handy and improves performance for the cases where it's Why is it so useful and "improves" performance so much?? I'll only believe this when I see some perf traces. Strings don't tend to be very long ( < 256). Thus an c*O(n), where c = (2 + 1 function call) doesn't sound like a big savings. Especially in the face of portability. I really think 99% of the programs using stpcpy() for "speed" reasons would spend 99% of their time elsewhere if p=strchr(strcpy(d,s), '\0'); were used. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 30 4:15:40 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 03F4D14DEB for ; Sat, 30 Oct 1999 04:15:34 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA06632 for ; Sat, 30 Oct 1999 13:15:32 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA46397 for freebsd-arch@freebsd.org; Sat, 30 Oct 1999 13:15:32 +0200 (MET DST) Received: from smtp05.wxs.nl (smtp05.wxs.nl [195.121.6.57]) by hub.freebsd.org (Postfix) with ESMTP id F3736150A5; Sat, 30 Oct 1999 04:15:05 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.196.85]) by smtp05.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA4F94; Sat, 30 Oct 1999 13:14:59 +0200 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id MAA43527; Sat, 30 Oct 1999 12:43:11 +0200 (CEST) (envelope-from asmodai) Date: Sat, 30 Oct 1999 12:43:10 +0200 From: Jeroen Ruigrok/Asmodai To: Chris Costello Cc: Warner Losh , obrien@freebsd.org, freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <19991030124309.A43205@daemon.ninth-circle.org> References: <19991029132257.A535@holly.calldei.com> <19991029111352.A87934@dragon.nuxi.com> <19991029132257.A535@holly.calldei.com> <199910291829.MAA89401@harmony.village.org> <19991029134549.B535@holly.calldei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <19991029134549.B535@holly.calldei.com> Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [19991030 00:00], Chris Costello (chris@calldei.com) wrote: >On Fri, Oct 29, 1999, Warner Losh wrote: >> In message <19991029132257.A535@holly.calldei.com> Chris Costello writes: >> : I'm seeing more and more of a need for a compat library for >> : Linux and GNU software in general. Adding unnecessary bloat to >> : our libc isn't necessary, in my opinion. >> >> The problem with this is that it becomes harder to build on FreeBSD >> because you have to add additional, non-standard libraries to the >> build process. This is the fault of the author of the tool, since >> they used non-standard interfaces, so maybe it wouldn't be too bad. >> The risk we run in not supporting them in libc is the perception that >> FreeBSD isn't compatible (never mind what the sstandards say). > > That's the problem. I honestly can't begin to think of a perfect >way of getting around Linux developers putting kludge after kludge >on top of poorly written workarounds on top of hacks that were never >really fully implemented (as far as libc goes). Put their >functions in our libc and we end up with a bigger, bloated libc. >Make a new library and cause trouble for people wanting to build >the latest greatest Linux program on FreeBSD. Yet still, we shouldn't follow suit to giving in to libc bloating. Basically what our Linux brothers are doing is creating aliases for often used functions/series of functions. I don't think we want to bloat the library with this. I already changed configure.in on a emulator port I am coding on to check for libgnugetopt and .h. I think we need, next to the linuxulator, also a compatlinux lib. And if this causes trouble for people wanting to build the latest and greatest, then so be it. I'd rather have our base system as slick, well-thought out and what not as it is now. (And yes I know I asked about adding some getopt stuff to unistd.h, but I revised my statement on that. ;) ) On the topic of having to add non-standard libraries before compilation, you can also argue that adding non-standard functions to a standards library is also a no-no. =) If I look at the libcompatlinux (or whatever name it would get) more closely I would probably see a (g)libc(5) which is stripped down from all duplicate stuff in order to avoid claches with -lc. On an aside, glibc changes things in their sources almost every day. That's how `stable' their libc is. Stable being stable in terms of touching the sources. -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project Network/Security Specialist BSD: Technical excellence at its best Man is the Dream of the dolphin... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 30 14:25: 3 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id EB20C14CA2 for ; Sat, 30 Oct 1999 14:24:48 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA11201 for ; Sat, 30 Oct 1999 23:24:45 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA62844 for freebsd-arch@freebsd.org; Sat, 30 Oct 1999 23:24:44 +0200 (MET DST) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 0BF2814CA2 for ; Sat, 30 Oct 1999 14:24:34 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id OAA04860; Sat, 30 Oct 1999 14:24:14 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpdAAAsnaOEj; Sat Oct 30 14:24:08 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA00920; Sat, 30 Oct 1999 14:24:22 -0700 (MST) From: Terry Lambert Message-Id: <199910302124.OAA00920@usr06.primenet.com> Subject: Re: Racing interrupts To: nate@mt.sri.com Date: Sat, 30 Oct 1999 21:24:21 +0000 (GMT) Cc: tlambert@primenet.com, rjesup@wgate.com, imp@village.org, arch@freebsd.org In-Reply-To: <199910291851.MAA05434@mt.sri.com> from "Nate Williams" at Oct 29, 99 12:51:41 pm X-Mailer: ELM [version 2.4 PL25] 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 don't believe in impossible > > OK, I want to fly w/out use of external devices. > > Oh, you mean with software? > > I want my computer to run 100X faster than it does now, w/out changing > any of the hardware! There is a difference between violation of physical laws, and a race window that is a result of a lack of code correctness. You have not demonstrated that the race window to which you refer is in fact an artifact of the hardware design, and not an artifact of the software design. You have practically admitted that this is the case, when you performed your analysis of the race in a PCMCIA/PCCARD utilyzing fast interrupts (answer: don't use fast interrupts, or make them an option for ejectable cards, which is defaulted to disabled). > > and I don't care about overhead if something is worth doing. > > Cool. I want you to start using my new compressed FS, which allows you > to store 3X as much data on your hard disk. Unfortunately, the overhead > of compressing/decompressing slows access to 1K/sec max., but it's worth > doing, so the overhead is irrelevant. > > In other words, do you realize how silly you sound? Not as silly as you sound, claiming that something which bounds your I/O to 1k/sec max is "worth doing". 8-). Note: to thwart your taking the I/O rate bounding strawman as a reson why PCMCIA/PCCARD devices should be allowed to use fast interrupts by default, I will quote Ed Lane: "I can make it go as fast as you want, so long as it doesn't have to work." 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 Sat Oct 30 14:28:25 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9039C15177 for ; Sat, 30 Oct 1999 14:28:15 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA11226 for ; Sat, 30 Oct 1999 23:28:13 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA62874 for freebsd-arch@freebsd.org; Sat, 30 Oct 1999 23:28:13 +0200 (MET DST) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 991941517C for ; Sat, 30 Oct 1999 14:27:59 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id OAA05316; Sat, 30 Oct 1999 14:27:14 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpdAAACcaypk; Sat Oct 30 14:27:08 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA00988; Sat, 30 Oct 1999 14:26:56 -0700 (MST) From: Terry Lambert Message-Id: <199910302126.OAA00988@usr06.primenet.com> Subject: Re: Racing interrupts To: imp@village.org (Warner Losh) Date: Sat, 30 Oct 1999 21:26:56 +0000 (GMT) Cc: doconnor@gsoft.com.au, chris@netmonger.net, freebsd-arch@freebsd.org In-Reply-To: <199910271627.KAA64604@harmony.village.org> from "Warner Losh" at Oct 27, 99 10:27:34 am X-Mailer: ELM [version 2.4 PL25] 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 > In message "Daniel > O'Connor" writes: > : Doesn't powering down the card work? > : Or does that pull the rug too? > > It depends. You need to detach the driver from the system, and then > you can safely remove power from the card. This usually will generate > an unfielded interrupt (since the card will have detached its ISR from > the vector), but that's usually the worst of it. Why will this generate an unfielded interrupt? Specifically, if the card has been correctly shut down before (or as a part of) the detach process, why would it generate an interrupt? 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 Sat Oct 30 15:10:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 80DB715186 for ; Sat, 30 Oct 1999 15:10:15 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA11573 for ; Sun, 31 Oct 1999 00:10:15 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA63036 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 00:10:14 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id C70CF15186 for ; Sat, 30 Oct 1999 15:10:08 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id QAA25867; Sat, 30 Oct 1999 16:09:50 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA10195; Sat, 30 Oct 1999 16:09:48 -0600 Date: Sat, 30 Oct 1999 16:09:48 -0600 Message-Id: <199910302209.QAA10195@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com, rjesup@wgate.com, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910302124.OAA00920@usr06.primenet.com> References: <199910291851.MAA05434@mt.sri.com> <199910302124.OAA00920@usr06.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > I don't believe in impossible > > > > OK, I want to fly w/out use of external devices. > > > > Oh, you mean with software? > > > > I want my computer to run 100X faster than it does now, w/out changing > > any of the hardware! > > > There is a difference between violation of physical laws, and > a race window that is a result of a lack of code correctness. And as I've stated already many times, in order to completely revmove the races from the system requires a violation of physical laws. > You have not demonstrated that the race window to which you > refer is in fact an artifact of the hardware design, and not > an artifact of the software design. Then you haven't paid attention. Please pay attention... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 30 15:22:48 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 10BE714CA2 for ; Sat, 30 Oct 1999 15:22:44 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA11655 for ; Sun, 31 Oct 1999 00:22:24 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA63093 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 00:22:24 +0200 (MET DST) Received: from arc.hq.cti.ru (arc.hq.cti.ru [195.34.40.3]) by hub.freebsd.org (Postfix) with ESMTP id 1E13214CA2; Sat, 30 Oct 1999 15:22:10 -0700 (PDT) (envelope-from dima@tejblum.pp.ru) Received: (from uucp@localhost) by arc.hq.cti.ru (8.9.3/8.9.3) with UUCP id CAA95430; Sun, 31 Oct 1999 02:22:08 +0400 (MSD) (envelope-from dima@tejblum.pp.ru) Received: from tejblum.pp.ru (localhost [127.0.0.1]) by tejblum.pp.ru (8.9.3/8.9.3) with ESMTP id CAA03763; Sun, 31 Oct 1999 02:28:50 +0400 (MSD) (envelope-from dima@tejblum.pp.ru) Message-Id: <199910302228.CAA03763@tejblum.pp.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: obrien@freebsd.org Cc: freebsd-arch@freebsd.org From: Dmitrij Tejblum Subject: Re: stpcpy() In-reply-to: Your message of "Fri, 29 Oct 1999 23:46:55 PDT." <19991029234654.B89583@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 Oct 1999 02:28:50 +0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David O'Brien" wrote: > Why is it so useful and "improves" performance so much?? Good stpcpy() could double performance in some cases. You would touch a symbol once where you previously touched it twice. It actually may matter in some text-processing applications. > Especially in the face of portability. For a programmer, there is no reason to lose the improvement (even small one) on some platforms (such as Windows :-), since a fallback implementation of stpcpy() is trivial. Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 30 15:23:51 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 94AB2151A1 for ; Sat, 30 Oct 1999 15:23:38 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA11675 for ; Sun, 31 Oct 1999 00:23:37 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA63115 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 00:23:37 +0200 (MET DST) Received: from arc.hq.cti.ru (arc.hq.cti.ru [195.34.40.3]) by hub.freebsd.org (Postfix) with ESMTP id E581414CA2 for ; Sat, 30 Oct 1999 15:23:20 -0700 (PDT) (envelope-from dima@tejblum.pp.ru) Received: (from uucp@localhost) by arc.hq.cti.ru (8.9.3/8.9.3) with UUCP id CAA95432; Sun, 31 Oct 1999 02:22:21 +0400 (MSD) (envelope-from dima@tejblum.pp.ru) Received: from tejblum.pp.ru (localhost [127.0.0.1]) by tejblum.pp.ru (8.9.3/8.9.3) with ESMTP id CAA03773; Sun, 31 Oct 1999 02:28:54 +0400 (MSD) (envelope-from dima@tejblum.pp.ru) Message-Id: <199910302228.CAA03773@tejblum.pp.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: chris@calldei.com Cc: freebsd-arch@freebsd.org From: Dmitrij Tejblum Subject: Re: stpcpy() In-reply-to: Your message of "Fri, 29 Oct 1999 15:13:17 CDT." <19991029151317.E535@holly.calldei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 Oct 1999 02:28:54 +0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris Costello wrote: > On Fri, Oct 29, 1999, Randell Jesup wrote: > > stpcpy() (the issue in this case) is something I've seen in > > compiler's C libraries since the late 80's/early 90's (if I remember > > correctly) Yes. > First it's stpcpy, then GNU getopt, then ... Yes. So what? You are suffering from the "NIH" disease. (BTW, stpcpy is not first and is not GNUism/Linuxism). > The bigger issue of Linux compatibility is essentially what > this is leading into. Currently the biggest users of stpcpy are > Linux applications. Frankly it's hard enough at this point to > deal with problems with the GNU getopt (awfully difficult to port > programs using GNU getopt without replicating the getopt() code > from glibc). At the same time, there are dozens of other Linux > compatibility issues. Putting all these new foreign library > calls into libc is not the solution unless we're interested in a > larger library. The argument "hardware is cheap" is not valid. I don't care about Linux compatibility. stpcpy() is an useful function, even if only little useful. There is no more reason to call it bloat than for asprintf(), or strsignal(), or even fts(), or strvis() or strlcpy(). GNU getopt has nothing to do with stpcpy() and cannot be a valid argument to not include stpcpy() in libc. Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 30 15:32:40 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 04E5215198 for ; Sat, 30 Oct 1999 15:32:36 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA11722 for ; Sun, 31 Oct 1999 00:32:33 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA63151 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 00:32:32 +0200 (MET DST) Received: from mta2.rcsntx.swbell.net (mta2.rcsntx.swbell.net [151.164.30.26]) by hub.freebsd.org (Postfix) with ESMTP id CF39415195 for ; Sat, 30 Oct 1999 15:32:24 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org ([216.62.157.60]) by mta2.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FKF00DKYT9XVA@mta2.rcsntx.swbell.net> for freebsd-arch@FreeBSD.ORG; Sat, 30 Oct 1999 17:32:22 -0500 (CDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id RAA00580; Sat, 30 Oct 1999 17:33:23 -0500 (CDT envelope-from chris) X-URL: http://www.FreeBSD.org/~chris/ Date: Sat, 30 Oct 1999 17:33:22 -0500 From: Chris Costello Subject: Re: stpcpy() In-reply-to: <199910302228.CAA03773@tejblum.pp.ru> To: Dmitrij Tejblum Cc: freebsd-arch@freebsd.org Reply-To: chris@calldei.com Message-id: <19991030173322.A472@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i X-Operating-System: FreeBSD 4.0-CURRENT (i386) References: <19991029151317.E535@holly.calldei.com> <199910302228.CAA03773@tejblum.pp.ru> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Oct 31, 1999, Dmitrij Tejblum wrote: > I don't care about Linux compatibility. stpcpy() is an useful > function, even if only little useful. There is no more reason to call > it bloat than for asprintf(), or strsignal(), or even fts(), or strvis() > or strlcpy(). GNU getopt has nothing to do with stpcpy() and cannot be > a valid argument to not include stpcpy() in libc. I wasn't associating GNU getopt with stpcpy. asprintf is very useful, I see nothing wrong with FTS (because it serves a large purpose), I'm not sure whether I like strsignal/strvis or not. And I was and still am against strlcpy. I don't think there should be any more bloat only to serve the purpose of compatibility with a bunch of Linux programs which use stpcpy(). (Regardless of whether stpcpy is a Linuxism or not, it's mostly a Linux thing now.) -- |Chris Costello |I modem, but they grew back. `---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 30 17: 5:45 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 18566151B7 for ; Sat, 30 Oct 1999 17:05:30 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA12508 for ; Sun, 31 Oct 1999 02:05:26 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA63494 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 02:05:25 +0200 (MET DST) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 82AF114D7A for ; Sat, 30 Oct 1999 17:04:51 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11hiUK-0007VO-00; Sat, 30 Oct 1999 18:04:48 -0600 Message-ID: <381B87A0.559C2CE7@softweyr.com> Date: Sat, 30 Oct 1999 18:04:48 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Warner Losh , freebsd-arch@freebsd.org Subject: Re: Racing interrupts References: <199910302126.OAA00988@usr06.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Specifically, if the card has been correctly shut down before > (or as a part of) the detach process, why would it generate > an interrupt? The card eject notification. -- "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 Sat Oct 30 20: 8:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2F00D14CC2 for ; Sat, 30 Oct 1999 20:08:16 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA13931 for ; Sun, 31 Oct 1999 04:08:15 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA63975 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 04:08:14 +0100 (MET) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id BB4F914DEC; Sat, 30 Oct 1999 20:07:41 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from p158-ts5.syd2.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id OAA27409; Sun, 31 Oct 1999 14:12:13 +1100 Date: Sun, 31 Oct 1999 14:07:26 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Dmitrij Tejblum Cc: obrien@freebsd.org, freebsd-arch@freebsd.org Subject: Re: stpcpy() In-Reply-To: <199910302228.CAA03763@tejblum.pp.ru> 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, 31 Oct 1999, Dmitrij Tejblum wrote: > "David O'Brien" wrote: > > Why is it so useful and "improves" performance so much?? > > Good stpcpy() could double performance in some cases. You would touch a > symbol once where you previously touched it twice. It actually may > matter in some text-processing applications. stpcpy() could halve performance in some cases (when the compiler inlines and combines strcpy() and strlen() but doesn't do anything special with stpcpy(), and inlining is good). In practice, gcc seems to only inline strlen(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 30 21:49:40 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 401CA14BD0 for ; Sat, 30 Oct 1999 21:49:37 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA14560 for ; Sun, 31 Oct 1999 05:49:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA64145 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 05:49:36 +0100 (MET) Received: from green.myip.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 7583F14BD0 for ; Sat, 30 Oct 1999 21:49:29 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost ([127.0.0.1] ident=green) by green.myip.org with esmtp (Exim 3.02 #1) id 11hmvV-000DMA-00; Sun, 31 Oct 1999 00:49:09 -0400 Date: Sun, 31 Oct 1999 00:49:08 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.myip.org To: Chris Costello Cc: Dmitrij Tejblum , freebsd-arch@freebsd.org Subject: Re: stpcpy() In-Reply-To: <19991030173322.A472@holly.calldei.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 Sat, 30 Oct 1999, Chris Costello wrote: > I wasn't associating GNU getopt with stpcpy. asprintf is very > useful, I see nothing wrong with FTS (because it serves a large > purpose), I'm not sure whether I like strsignal/strvis or not. Except FTS is horrible, evil code... > > -- > |Chris Costello > |I modem, but they grew back. > `---------------------------------- -- 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 Sat Oct 30 22:29:58 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6A8CE14CC7 for ; Sat, 30 Oct 1999 22:29:55 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA14803 for ; Sun, 31 Oct 1999 06:29:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA64227 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 06:29:53 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 78E4C14CC7 for ; Sat, 30 Oct 1999 22:29:46 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA55776; Sat, 30 Oct 1999 23:29:40 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA98996; Sat, 30 Oct 1999 23:31:31 -0600 (MDT) Message-Id: <199910310531.XAA98996@harmony.village.org> To: Terry Lambert Subject: Re: Racing interrupts Cc: doconnor@gsoft.com.au, chris@netmonger.net, freebsd-arch@freebsd.org In-reply-to: Your message of "Sat, 30 Oct 1999 21:26:56 -0000." <199910302126.OAA00988@usr06.primenet.com> References: <199910302126.OAA00988@usr06.primenet.com> Date: Sat, 30 Oct 1999 23:31:31 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199910302126.OAA00988@usr06.primenet.com> Terry Lambert writes: : Specifically, if the card has been correctly shut down before : (or as a part of) the detach process, why would it generate : an interrupt? It doesn't generate the interrupt. The pcic chip apparently does, which is why you have to be very careful. At least that's what my limited research has shown. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 30 22:31:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8574014CC7 for ; Sat, 30 Oct 1999 22:31:24 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA14818 for ; Sun, 31 Oct 1999 06:31:23 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA64253 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 06:31:23 +0100 (MET) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 25FF814CC7 for ; Sat, 30 Oct 1999 22:31:04 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id XAA22921 for freebsd-arch@FreeBSD.ORG; Sat, 30 Oct 1999 23:31:04 -0600 (MDT) (envelope-from ken) Message-Id: <199910310531.XAA22921@panzer.kdm.org> Subject: replacing pci/pci_ioctl.h with sys/pciio.h To: freebsd-arch@freebsd.org Date: Sat, 30 Oct 1999 23:31:04 -0600 (MDT) From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 Here's a set of patches (against -current from a couple of days ago) to replace pci/pci_ioctl.h with sys/pciio.h. Since random header files from sys/pci aren't installed in /usr/include (and shouldn't be), it makes it difficult for userland applications to use the PCI ioctl interface. pciconf(8) just adjusts its include path to pull in the current header, but the Alpha XFree86 port has to do some hackery to pull in the right source file. This also includes a man page for pci(4). Steve Price has tested this with buildworlds and GENERIC kernel builds on both Alpha and i386. Any objections or (relevant!) comments? Ken -- Kenneth Merry ken@kdm.org Index: share/man/man4/Makefile =================================================================== RCS file: /home/ncvs/src/share/man/man4/Makefile,v retrieving revision 1.59 diff -u -r1.59 Makefile --- Makefile 1999/08/22 23:40:40 1.59 +++ Makefile 1999/10/24 15:52:28 @@ -5,7 +5,7 @@ icmp.4 ifmib.4 iic.4 iicbb.4 iicbus.4 iicsmb.4 \ inet.4 intpm.4 intro.4 ip.4 ipfirewall.4 kld.4 \ lo.4 lp.4 lpbb.4 lpt.4 natm.4 netintro.4 \ - null.4 pass.4 ppbus.4 ppi.4 ppp.4 pt.4 pty.4 \ + null.4 pass.4 pci.4 ppbus.4 ppi.4 ppp.4 pt.4 pty.4 \ route.4 sa.4 scsi.4 \ sd.4 sl.4 smb.4 smbus.4 smp.4 snp.4 sppp.4 ssc.4 st.4 su.4 tcp.4 \ termios.4 ttcp.4 tty.4 tun.4 udp.4 uk.4 unix.4 update.4 vinum.4 vn.4 \ Index: share/man/man4/pci.4 =================================================================== RCS file: pci.4 diff -N pci.4 --- /dev/null Sun Oct 24 10:45:05 1999 +++ pci.4 Sun Oct 24 10:46:32 1999 @@ -0,0 +1,295 @@ +.\" +.\" Copyright (c) 1999 Kenneth D. Merry. +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. The name of the author may not be used to endorse or promote products +.\" derived from this software without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd October 24, 1999 +.Dt PCI 4 +.Os FreeBSD 4.0 +.Sh NAME +.Nm pci +.Nd Generic PCI driver +.Sh SYNOPSYIS +.Cd controller pci0 +.Sh DESCRIPTION +The +.Nm pci +driver provides a way for userland programs to read and write +.Tn PCI +configuration registers. It also provides a way for userland programs to +get a list of all +.Tn PCI +devices, or all +.Tn PCI +devices that match various patterns. +.Pp +Since the +.Nm pci +driver provides a write interface for +.Tn PCI +configuration registers, system administrators should exercise caution when +granting access to the +.Nm pci +device. If used improperly, this driver can allow userland applications to +crash a machine or cause data loss. +.Sh KERNEL CONFIGURATION +It is only necessary to specify one +.Nm pci +controller in the kernel. Additional +.Tn PCI +busses are handled automatically as they are encountered. +.Sh IOCTLS +The following +.Xr ioctl 2 +calls are supported by the +.Nm pci +driver. They are defined in the header file +.Aq Pa sys/pciio.h . +.Bl -tag -width 012345678901234 +.Pp +.It PCIOCGETCONF +This +.Xr ioctl 2 +takes a +.Va pci_conf_io +structure. It allows the user to retrieve information on all +.Tn PCI +devices in the system, or on +.Tn PCI +devices matching patterns supplied by the user. +The +.Va pci_conf_io +structure consists of a number of fields: +.Bl -tag -width match_buf_len +.It pat_buf_len +The length, in bytes, of the buffer filled with user-supplied patterns. +.It num_patterns +The number of user-supplied patterns. +.It patterns +Pointer to a buffer filled with user-supplied patterns. +.Va patterns +is a pointer to +.Va num_patterns +.Va pci_match_conf +structures. The +.Va pci_match_conf +structure consists of the following elements: +.Bl -tag -width pd_vendor +.It pc_sel +.Tn PCI +bus, slot and function. +.It pd_name +.Tn PCI +device driver name. +.It pd_unit +.Tn PCI +device driver unit number. +.It pc_vendor +.Tn PCI +vendor ID. +.It pc_device +.Tn PCI +device ID. +.It pc_class +.Tn PCI +device class. +.It flags +The flags describe which of the fields the kernel should match against. +A device must match all specified fields in order to be returned. The +match flags are enumerated in the +.Va pci_getconf_flags +structure. +Hopefully the flag values are obvious enough that they don't need to +described in detail. +.El +.It match_buf_len +Length of the +.Va matches +buffer allocated by the user to hold the results of the +.Dv PCIOCGETCONF +query. +.It num_matches +Number of matches returned by the kernel. +.It matches +Buffer containing matching devices returned by the kernel. The items in +this buffer are of type +.Va pci_conf , +which consists of the following items: +.Bl -tag -width pc_subvendor +.It pc_sel +.Tn PCI +bus, slot and function. +.It pc_hdr +.Tn PCI +header type. +.It pc_subvendor +.Tn PCI +subvendor ID. +.It pc_subdevice +.Tn PCI +subdevice ID. +.It pc_vendor +.Tn PCI +vendor ID. +.It pc_device +.Tn PCI +device ID. +.It pc_class +.Tn PCI +device class. +.It pc_subclass +.Tn PCI +device subclass. +.It pc_progif +.Tn PCI +device programming interface. +.It pc_revid +.Tn PCI +revision ID. +.It pd_name +Driver name. +.It pd_unit +Driver unit number. +.El +.It offset +The offset is passed in by the user to tell the kernel where it should +start traversing the device list. The value passed out by the kernel +points to the record immediately after the last one returned. The user may +pass the value returned by the kernel in subsequent calls to the +.Dv PCIOCGETCONF +ioctl. If the user does not intend to use the offset, it must be set to +zero. +.It generation +.Tn PCI +configuration generation. This value only needs to be set if the offset is +set. The kernel will compare the current generation number of its internal +device list to the generation passed in by the user to determine whether +its device list has changed since the user last called the +.Dv PCIOCGETCONF +ioctl. If the device list has changed, a status of +.Va PCI_GETCONF_LIST_CHANGED +will be passed back. +.It status +The status tells the user the disposition of his request for a device list. +The possible status values are: +.Bl -ohang +.It PCI_GETCONF_LAST_DEVICE +This means that there are no more devices in the PCI device list after the +ones returned in the +.Va matches +buffer. +.It PCI_GETCONF_LIST_CHANGED +This status tells the user that the +.Tn PCI +device list has changed since his last call to the +.Dv PCIOCGETCONF +ioctl and he must reset the +.Va offset +and +.Va generation +to zero to start over at the beginning of the list. +.It PCI_GETCONF_MORE_DEVS +This tells the user that his buffer was not large enough to hold all of the +remaining devices in the device list that possibly match his criteria. It +is possible for this status to be returned, even when none of the remaining +devices in the list would match the user's criteria. +.It PCI_GETCONF_ERROR +This indicates a general error while servicing the user's request. A more +specific indication of the problem may or may not be printed in the kernel +message buffer (and by implication, the system console). +.El +.El +.It PCIOCREAD +This +.Xr ioctl 2 +reads the +.Tn PCI +configuration registers specified by the passed-in +.Va pci_io +structure. The +.Va pci_io +structure consists of the following fields: +.Bl -tag -width pi_width +.It pi_sel +A +.Va pcisel +structure which specifies the bus, slot and function the user would like to +query. +.It pi_reg +The +.Tn PCI +configuration register the user would like to access. +.It pi_width +The width, in bytes, of the data the user would like to read. This value +may be either 1, 2, or 4. 3-byte reads and reads larger than 4 bytes are +not supported. +.It pi_data +The data returned by the kernel. +.El +.It PCIOCWRITE +This +.Xr ioctl 2 +allows users to write to the +.Tn PCI +specified in the passed-in +.Va pci_io +structure. The +.Va pci_io +structure is described above. The limitations on data width described for +reading registers, above, also apply to writing +.Tn PCI +configuration registers. +.El +.Sh FILES +.Bl -tag -width 01234567890 -compact +.It Pa /dev/pci +Character device for the +.Nm pci +driver. +.El +.Sh DIAGNOSTICS +None. +.Sh SEE ALSO +.Xr pciconf 8 +.Sh HISTORY +The +.Nm pci +driver (not the kernel's +.Tn PCI +support code) first appeared in +.Fx 2.2 , +and was written by Stefan Esser and Garrett Wollman. +Support for device listing and matching was re-implemented by +Kenneth Merry, and first appeared in +.Fx 3.0 . +.Sh AUTHORS +.An Kenneth Merry Aq ken@FreeBSD.ORG +.Sh BUGS +It isn't possible for users to specify an accurate offset into the device +list without calling the +.Dv PCIOCGETCONF +at least once, since they have no way of knowing the current generation +number otherwise. This probably isn't a serious problem, though, since +users can easily narrow their search by specifying a pattern or patterns +for the kernel to match against. Index: sys/alpha/alpha/dec_2100_a50.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/dec_2100_a50.c,v retrieving revision 1.4 diff -u -r1.4 dec_2100_a50.c --- dec_2100_a50.c 1999/10/05 21:19:33 1.4 +++ dec_2100_a50.c 1999/10/24 15:52:42 @@ -45,7 +45,6 @@ #include #include #include -#include #include #include Index: sys/alpha/alpha/dec_axppci_33.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/dec_axppci_33.c,v retrieving revision 1.5 diff -u -r1.5 dec_axppci_33.c --- dec_axppci_33.c 1999/10/05 21:19:34 1.5 +++ dec_axppci_33.c 1999/10/24 15:52:53 @@ -42,7 +42,6 @@ #include #include #include -#include #include #include "sio.h" Index: sys/alpha/alpha/dec_eb64plus.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/dec_eb64plus.c,v retrieving revision 1.3 diff -u -r1.3 dec_eb64plus.c --- dec_eb64plus.c 1999/10/05 21:19:34 1.3 +++ dec_eb64plus.c 1999/10/24 15:53:03 @@ -60,7 +60,6 @@ #include #include -#include #include #include Index: sys/alpha/alpha/dec_kn20aa.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/dec_kn20aa.c,v retrieving revision 1.6 diff -u -r1.6 dec_kn20aa.c --- dec_kn20aa.c 1999/10/05 21:19:34 1.6 +++ dec_kn20aa.c 1999/10/24 15:53:23 @@ -42,7 +42,6 @@ #include #include #include -#include #include #include Index: sys/alpha/alpha/dec_st550.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/dec_st550.c,v retrieving revision 1.4 diff -u -r1.4 dec_st550.c --- dec_st550.c 1999/10/05 21:19:34 1.4 +++ dec_st550.c 1999/10/24 15:53:32 @@ -48,7 +48,6 @@ #include #include #include -#include #include #include Index: sys/alpha/alpha/dec_st6600.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/dec_st6600.c,v retrieving revision 1.3 diff -u -r1.3 dec_st6600.c --- dec_st6600.c 1999/10/05 21:19:34 1.3 +++ dec_st6600.c 1999/10/24 15:53:39 @@ -41,7 +41,6 @@ #include #include #include -#include #include #include Index: sys/pci/pci.c =================================================================== RCS file: /home/ncvs/src/sys/pci/pci.c,v retrieving revision 1.123 diff -u -r1.123 pci.c --- pci.c 1999/10/17 06:48:47 1.123 +++ pci.c 1999/10/24 15:53:49 @@ -54,7 +54,7 @@ #include #include -#include +#include #ifdef APIC_IO #include Index: sys/pci/pci_ioctl.h =================================================================== RCS file: pci_ioctl.h diff -N pci_ioctl.h --- /tmp/cvse16454 Sun Oct 24 11:14:40 1999 +++ /dev/null Sun Oct 24 10:45:05 1999 @@ -1,128 +0,0 @@ -#ifndef _PCI_IOCTL_H -#define _PCI_IOCTL_H 1 - -#include - - -#define PCI_MAXNAMELEN 16 /* max no. of characters in a device name */ - -typedef enum { - PCI_GETCONF_LAST_DEVICE, - PCI_GETCONF_LIST_CHANGED, - PCI_GETCONF_MORE_DEVS, - PCI_GETCONF_ERROR -} pci_getconf_status; - -typedef enum { - PCI_GETCONF_NO_MATCH = 0x00, - PCI_GETCONF_MATCH_BUS = 0x01, - PCI_GETCONF_MATCH_DEV = 0x02, - PCI_GETCONF_MATCH_FUNC = 0x04, - PCI_GETCONF_MATCH_NAME = 0x08, - PCI_GETCONF_MATCH_UNIT = 0x10, - PCI_GETCONF_MATCH_VENDOR = 0x20, - PCI_GETCONF_MATCH_DEVICE = 0x40, - PCI_GETCONF_MATCH_CLASS = 0x80 -} pci_getconf_flags; - -struct pcisel { - u_int8_t pc_bus; /* bus number */ - u_int8_t pc_dev; /* device on this bus */ - u_int8_t pc_func; /* function on this device */ -}; - -struct pci_conf { - struct pcisel pc_sel; /* bus+slot+function */ - u_int8_t pc_hdr; /* PCI header type */ - u_int16_t pc_subvendor; /* card vendor ID */ - u_int16_t pc_subdevice; /* card device ID, assigned by - card vendor */ - u_int16_t pc_vendor; /* chip vendor ID */ - u_int16_t pc_device; /* chip device ID, assigned by - chip vendor */ - u_int8_t pc_class; /* chip PCI class */ - u_int8_t pc_subclass; /* chip PCI subclass */ - u_int8_t pc_progif; /* chip PCI programming interface */ - u_int8_t pc_revid; /* chip revision ID */ - char pd_name[PCI_MAXNAMELEN + 1]; /* Name of peripheral - device */ - u_long pd_unit; /* Unit number */ -}; - -struct pci_match_conf { - struct pcisel pc_sel; /* bus+slot+function */ - char pd_name[PCI_MAXNAMELEN + 1]; /* Name of peripheral - device */ - u_long pd_unit; /* Unit number */ - u_int16_t pc_vendor; /* PCI Vendor ID */ - u_int16_t pc_device; /* PCI Device ID */ - u_int8_t pc_class; /* PCI class */ - pci_getconf_flags flags; /* Matching expression */ -}; - -struct pci_conf_io { - u_int32_t pat_buf_len; /* - * Length of buffer passed in from - * user space. - */ - u_int32_t num_patterns; /* - * Number of pci_match_conf structures - * passed in by the user. - */ - struct pci_match_conf *patterns; /* - * Patterns passed in by the user. - */ - u_int32_t match_buf_len;/* - * Length of match buffer passed - * in by the user. - */ - u_int32_t num_matches; /* - * Number of matches returned by - * the kernel. - */ - struct pci_conf *matches; /* - * PCI device matches returned by - * the kernel. - */ - u_int32_t offset; /* - * Passed in by the user code to - * indicate where the kernel should - * start traversing the device list. - * The value passed out by the kernel - * points to the record immediately - * after the last one returned. - * i.e. this value may be passed back - * unchanged by the user for a - * subsequent call. - */ - u_int32_t generation; /* - * PCI configuration generation. - * This only needs to be set if the - * offset is set. The kernel will - * compare its current generation - * number to the generation passed - * in by the user to determine - * whether the PCI device list has - * changed since the user last - * called the GETCONF ioctl. - */ - pci_getconf_status status; /* - * Status passed back from the - * kernel. - */ -}; - -struct pci_io { - struct pcisel pi_sel; /* device to operate on */ - int pi_reg; /* configuration register to examine */ - int pi_width; /* width (in bytes) of read or write */ - u_int32_t pi_data; /* data to write or result of read */ -}; - - -#define PCIOCGETCONF _IOWR('p', 1, struct pci_conf_io) -#define PCIOCREAD _IOWR('p', 2, struct pci_io) -#define PCIOCWRITE _IOWR('p', 3, struct pci_io) -#define PCIOCATTACHED _IOWR('p', 4, struct pci_io) - -#endif /* _PCI_IOCTL_H */ Index: sys/pci/pcivar.h =================================================================== RCS file: /home/ncvs/src/sys/pci/pcivar.h,v retrieving revision 1.36 diff -u -r1.36 pcivar.h --- pcivar.h 1999/10/14 21:38:33 1.36 +++ pcivar.h 1999/10/24 15:54:02 @@ -34,7 +34,6 @@ #define PCI_COMPAT #endif -#include /* XXX KDM */ #include /* some PCI bus constants */ Index: sys/sys/pciio.h =================================================================== RCS file: pciio.h diff -N pciio.h --- /dev/null Sun Oct 24 10:45:05 1999 +++ pciio.h Sun Oct 24 10:47:03 1999 @@ -0,0 +1,115 @@ +/*- + * Copyright (c) 1997, Stefan Esser + * Copyright (c) 1997, 1998, 1999, Kenneth D. Merry + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice unmodified, this list of conditions, and the following + * disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + * + */ + +#ifndef _SYS_PCIIO_H_ +#define _SYS_PCIIO_H_ + +#include + +#define PCI_MAXNAMELEN 16 + +typedef enum { + PCI_GETCONF_LAST_DEVICE, + PCI_GETCONF_LIST_CHANGED, + PCI_GETCONF_MORE_DEVS, + PCI_GETCONF_ERROR +} pci_getconf_status; + +typedef enum { + PCI_GETCONF_NO_MATCH = 0x00, + PCI_GETCONF_MATCH_BUS = 0x01, + PCI_GETCONF_MATCH_DEV = 0x02, + PCI_GETCONF_MATCH_FUNC = 0x04, + PCI_GETCONF_MATCH_NAME = 0x08, + PCI_GETCONF_MATCH_UNIT = 0x10, + PCI_GETCONF_MATCH_VENDOR = 0x20, + PCI_GETCONF_MATCH_DEVICE = 0x40, + PCI_GETCONF_MATCH_CLASS = 0x80 +} pci_getconf_flags; + +struct pcisel { + u_int8_t pc_bus; /* bus number */ + u_int8_t pc_dev; /* device on this bus */ + u_int8_t pc_func; /* function on this device */ +}; + +struct pci_conf { + struct pcisel pc_sel; /* bus+slot+function */ + u_int8_t pc_hdr; /* PCI header type */ + u_int16_t pc_subvendor; /* card vendor ID */ + u_int16_t pc_subdevice; /* card device ID, assigned by + card vendor */ + u_int16_t pc_vendor; /* chip vendor ID */ + u_int16_t pc_device; /* chip device ID, assigned by + chip vendor */ + u_int8_t pc_class; /* chip PCI class */ + u_int8_t pc_subclass; /* chip PCI subclass */ + u_int8_t pc_progif; /* chip PCI programming interface */ + u_int8_t pc_revid; /* chip revision ID */ + char pd_name[PCI_MAXNAMELEN + 1]; /* device name */ + u_long pd_unit; /* device unit number */ +}; + +struct pci_match_conf { + struct pcisel pc_sel; /* bus+slot+function */ + char pd_name[PCI_MAXNAMELEN + 1]; /* device name */ + u_long pd_unit; /* Unit number */ + u_int16_t pc_vendor; /* PCI Vendor ID */ + u_int16_t pc_device; /* PCI Device ID */ + u_int8_t pc_class; /* PCI class */ + pci_getconf_flags flags; /* Matching expression */ +}; + +struct pci_conf_io { + u_int32_t pat_buf_len; /* pattern buffer length */ + u_int32_t num_patterns; /* number of patterns */ + struct pci_match_conf *patterns; /* pattern buffer */ + u_int32_t match_buf_len; /* match buffer length */ + u_int32_t num_matches; /* number of matches returned */ + struct pci_conf *matches; /* match buffer */ + u_int32_t offset; /* offset into device list */ + u_int32_t generation; /* device list generation */ + pci_getconf_status status; /* request status */ +}; + +struct pci_io { + struct pcisel pi_sel; /* device to operate on */ + int pi_reg; /* configuration register to examine */ + int pi_width; /* width (in bytes) of read or write */ + u_int32_t pi_data; /* data to write or result of read */ +}; + + +#define PCIOCGETCONF _IOWR('p', 1, struct pci_conf_io) +#define PCIOCREAD _IOWR('p', 2, struct pci_io) +#define PCIOCWRITE _IOWR('p', 3, struct pci_io) +#define PCIOCATTACHED _IOWR('p', 4, struct pci_io) + +#endif /* !_SYS_PCIIO_H_ */ Index: usr.sbin/pciconf/pciconf.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/pciconf/pciconf.c,v retrieving revision 1.9 diff -u -r1.9 pciconf.c --- pciconf.c 1999/08/28 01:17:39 1.9 +++ pciconf.c 1999/10/24 15:54:10 @@ -40,9 +40,7 @@ #include #include #include - -#include -#include +#include #include "pathnames.h" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 30 23:14:24 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E056F14DC4 for ; Sat, 30 Oct 1999 23:14:21 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA15068 for ; Sun, 31 Oct 1999 07:14:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA64321 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 07:14:20 +0100 (MET) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 713B114DC4; Sat, 30 Oct 1999 23:14:10 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id QAA06978; Sun, 31 Oct 1999 16:43:59 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199910291829.MAA89401@harmony.village.org> Date: Sun, 31 Oct 1999 16:43:59 +0930 (CST) From: "Daniel O'Connor" To: Warner Losh Subject: Re: stpcpy() Cc: freebsd-arch@freebsd.org, obrien@freebsd.org, chris@calldei.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 29-Oct-99 Warner Losh wrote: > The problem with this is that it becomes harder to build on FreeBSD > because you have to add additional, non-standard libraries to the > build process. This is the fault of the author of the tool, since > they used non-standard interfaces, so maybe it wouldn't be too bad. > The risk we run in not supporting them in libc is the perception that > FreeBSD isn't compatible (never mind what the sstandards say). Well if you have a port which has this stuff in it (stpcpy, getopt, etc) then where's the problem? If you are building by hand adding -I/usr/local/include and -lcompatlinux to your makefile is easy, and if its a port its transparent to the end user. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message