From imp at bsdimp.com Fri Sep 4 22:19:33 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Sep 4 22:19:40 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <3bbf2fe10909041455u552b0dbdm1708ea0a26365149@mail.gmail.com> References: <200909031340.n83Defkv034013@svn.freebsd.org> <20090904.112919.1521002024.imp@bsdimp.com> <3bbf2fe10909041455u552b0dbdm1708ea0a26365149@mail.gmail.com> Message-ID: <20090904.161634.-217944108.imp@bsdimp.com> [[ redirected to arch@ since too much of this discussion has been private ]] In message: <3bbf2fe10909041455u552b0dbdm1708ea0a26365149@mail.gmail.com> Attilio Rao writes: : 2009/9/4 M. Warner Losh : : > In message: <200909031340.n83Defkv034013@svn.freebsd.org> : > Attilio Rao writes: : > : Modified: head/sys/sys/bus.h : > : ============================================================================== : > : --- head/sys/sys/bus.h Thu Sep 3 12:41:00 2009 (r196778) : > : +++ head/sys/sys/bus.h Thu Sep 3 13:40:41 2009 (r196779) : > : @@ -52,8 +52,11 @@ struct u_businfo { : > : typedef enum device_state { : > : DS_NOTPRESENT, /**< @brief not probed or probe failed */ : > : DS_ALIVE, /**< @brief probe succeeded */ : > : + DS_ATTACHING, /**< @brief attaching is in progress */ : > : DS_ATTACHED, /**< @brief attach method called */ : > : - DS_BUSY /**< @brief device is open */ : > : + DS_BUSY, /**< @brief device is open */ : > : + DS_DETACHING /**< @brief detaching is in progress */ : > : + : > : } device_state_t; : > : > device_state_t is exported to userland via devctl. Well, that's not : > entirely true... It isn't used EXACTLY, but there's this in : > devinfo.h: : > : > /* : > * State of the device. : > */ : > /* XXX not sure if I want a copy here, or expose sys/bus.h */ : > typedef enum devinfo_state { : > DIS_NOTPRESENT, /* not probed or probe failed */ : > DIS_ALIVE, /* probe succeeded */ : > DIS_ATTACHED, /* attach method called */ : > DIS_BUSY /* device is open */ : > } devinfo_state_t; : > : > which is why devinfo is broken. : : I think the right fix here is to maintain in sync devinfo.h and bus.h : definition by just having one. I see that the devices states are : redefined in devinfo.h in order to avoid namespace pollution and this : is a good point. What I propose is to add a new header (_bus.h, to be : included in both bus.h and devinfo.h) which just containst the device : states. There's a lot of possible fixes. It is broken right now. Your commit broke it. The problem is that we have multiple names for the same things, and that's a defined API/ABI today.... So having a _bus.h won't solve this problem without introducing name space pollution (well, I suppose you could have __DS_NOTPRESENT, __DS_ALIVE, etc and then have devinfo.h and bus.h map those in, but that still wouldn't totally solve the problem). : > Also, DS_BUSY is used in many drivers to PREVENT detaching. So the : > change is bad from that point of view, since DS_DETACHING is now > : > DS_BUSY. There's really a partial ordering relationship now where : > before there was a total ordering (DS_BUSY is > DS_ATTACHED and : > DS_DETACHING is > DS_ATTACH, but DS_DETACHING isn't > DS_BUSY and : > DS_BUSY isn't > DS_DETACHING). I think that you've destroyed : > information here by unconditionally setting it: : > : > - if ((error = DEVICE_DETACH(dev)) != 0) : > + dev->state = DS_DETACHING; : > + if ((error = DEVICE_DETACH(dev)) != 0) { : > + KASSERT(dev->state == DS_DETACHING, : > + ("%s: %p device state must not been changing", __func__, : > + dev)); : > + dev->state = DS_ATTACHED; : > return (error); : > + } : > + KASSERT(dev->state == DS_DETACHING, : > + ("%s: %p device state must not been changing", __func__, dev)); : > : > And this looks racy between the check earlier and this setting. : > Properly locked, this wouldn't destroy information... : : Sorry, I really don't understand what point are you making here, and : what the scaring words of "destroying", "racy", etc. means. Can you : explain better that part? I think it is a minor concern. There's no locking now to prevent multiple threads doing stuff. I think it would be better to completely omit this stuff than to put it in 1/2 way. Also, it breaks the linear nature of device_state_t. : > At the very least cardbus/cardbus.c and pccard/pccard.c need to be : > looked at since they both have code that looks like: : > : > for (tmp = 0; tmp < numdevs; tmp++) { : > struct cardbus_devinfo *dinfo = device_get_ivars(devlist[tmp]); : > int status = device_get_state(devlist[tmp]); : > : > if (dinfo->pci.cfg.dev != devlist[tmp]) : > device_printf(cbdev, "devinfo dev mismatch\n"); : > if (status == DS_ATTACHED || status == DS_BUSY) : > device_detach(devlist[tmp]); : > cardbus_release_all_resources(cbdev, dinfo); : > cardbus_device_destroy(dinfo); : > device_delete_child(cbdev, devlist[tmp]); : > pci_freecfg((struct pci_devinfo *)dinfo); : > } : > : > which does ignore errors returned by device_detach for the DS_BUSY : > case because there's not currently a good way to tell device_detach : > that it *MUST* detach the device *NOW* without any possibility of veto : > by the driver. The above code also isn't DS_DETACHING aware, and may : > be wrong in the face of this new state. : : How DS_DETACHING can cause problems here? device_detach() simply won't : run if the state is DS_DETACHING as expected (another thread is alredy : detaching and there is no need for it to detach). : Also, please note that in this case, for the state == DS_BUSY he : device_detach() won't do anything. You can't simply skip the return : value and anything else, but the reality is still the operation won't : happen. I explained about partial ordering already. Let me try again. DS_BUSY isn't compatible with this definition. It would be better to merge DS_ATTACHING and DS_DETACHING into one state, say DS_TRANSITION. Then we'd do the attach sequence as DS_ALIVE -> DS_TRANSITION -> DS_ATTACHED (and later DS_BUSY maybe). Then detach would go from DS_ATTACHED -> DS_TRANSITION to tear it down. There's a strong ordering expected in the code, and finding all the subtle places that this extra state beyond DS_BUSY causes problems will be hard. I'm not entirely sure how DS_DETACHING can cause problems here. However, I've not looked at all the possible code paths and such to make sure that there isn't a problem. Given the strong ordering of device_state_t that's present today, I'm not so glib that it would cause no problems. I want strong assurance that it won't. If we use DS_TRANSITION, then I know it won't. It would solve the problems with only one new state, and would preserve the ordering that's implicit in the code and hard to ferret out. This is only one example. : > Of course, grepping the tree does show one or two places where DS_BUSY : > is used inappropriately: : > : > rp.c: : > : > static int : > rp_pcidetach(device_t dev) : > { : > CONTROLLER_t *ctlp; : > : > if (device_get_state(dev) == DS_BUSY) : > return (EBUSY); : > : > is one example. The above check should just be removed (ditto for its : > SHUTDOWN) routine. : > : > So I think we should fix rp.c, but we need to talk through this change : > a little more. I'm surprised I wasn't even pinged about it, since it : > hits code that I maintain and a simple grep would have found... : : Still, I don't see a problem with the codes you mentioned (if not in : the consumers, which were alredy "broken" before this change and which : situation is not worse now), unless the devinfo breakage. Well, the rp.c that I talked about is a minor breakage that can easily be fixed. It is unrelated to your changes, but my grep found the breakage... devinfo breakage, however is a bigger deal, as is the breaking of the linearness of device_state_t. Let's just use one new state. It won't make locking harder, and will also prevent a device from attaching while someone else is detaching it better. In summary: I support adding one new state (and only one new state) to device_state_t that is numerically smaller than DS_ATTACHED. I think we should take this opportunity to make the states sparser as well (since that would allow us to insert them in the future, should a proven need be found). I think that the extra checks that were added to subr_bus.c should be backed out. I think that only the new state enums and their new values should be MFC'd. I further thing that *ALL* future discussions of newbus ABI/API changes go through arch@. In short, I think that http://people.freebsd.org/~imp/newbus-20090904 should be committed and MFC'd. I've not addressed the devinfo breakage yet... Warner From attilio at freebsd.org Fri Sep 4 23:18:22 2009 From: attilio at freebsd.org (Attilio Rao) Date: Fri Sep 4 23:18:29 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <20090904.161634.-217944108.imp@bsdimp.com> References: <200909031340.n83Defkv034013@svn.freebsd.org> <20090904.112919.1521002024.imp@bsdimp.com> <3bbf2fe10909041455u552b0dbdm1708ea0a26365149@mail.gmail.com> <20090904.161634.-217944108.imp@bsdimp.com> Message-ID: <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> 2009/9/5 M. Warner Losh : > [[ redirected to arch@ since too much of this discussion has been private ]] > > In message: <3bbf2fe10909041455u552b0dbdm1708ea0a26365149@mail.gmail.com> > Attilio Rao writes: > : 2009/9/4 M. Warner Losh : > : > In message: <200909031340.n83Defkv034013@svn.freebsd.org> > : > Attilio Rao writes: > : > : Modified: head/sys/sys/bus.h > : > : ============================================================================== > : > : --- head/sys/sys/bus.h Thu Sep 3 12:41:00 2009 (r196778) > : > : +++ head/sys/sys/bus.h Thu Sep 3 13:40:41 2009 (r196779) > : > : @@ -52,8 +52,11 @@ struct u_businfo { > : > : typedef enum device_state { > : > : DS_NOTPRESENT, /**< @brief not probed or probe failed */ > : > : DS_ALIVE, /**< @brief probe succeeded */ > : > : + DS_ATTACHING, /**< @brief attaching is in progress */ > : > : DS_ATTACHED, /**< @brief attach method called */ > : > : - DS_BUSY /**< @brief device is open */ > : > : + DS_BUSY, /**< @brief device is open */ > : > : + DS_DETACHING /**< @brief detaching is in progress */ > : > : + > : > : } device_state_t; > : > > : > device_state_t is exported to userland via devctl. Well, that's not > : > entirely true... It isn't used EXACTLY, but there's this in > : > devinfo.h: > : > > : > /* > : > * State of the device. > : > */ > : > /* XXX not sure if I want a copy here, or expose sys/bus.h */ > : > typedef enum devinfo_state { > : > DIS_NOTPRESENT, /* not probed or probe failed */ > : > DIS_ALIVE, /* probe succeeded */ > : > DIS_ATTACHED, /* attach method called */ > : > DIS_BUSY /* device is open */ > : > } devinfo_state_t; > : > > : > which is why devinfo is broken. > : > : I think the right fix here is to maintain in sync devinfo.h and bus.h > : definition by just having one. I see that the devices states are > : redefined in devinfo.h in order to avoid namespace pollution and this > : is a good point. What I propose is to add a new header (_bus.h, to be > : included in both bus.h and devinfo.h) which just containst the device > : states. > > There's a lot of possible fixes. It is broken right now. Your commit > broke it. > > The problem is that we have multiple names for the same things, and > that's a defined API/ABI today.... So having a _bus.h won't solve > this problem without introducing name space pollution (well, I suppose > you could have __DS_NOTPRESENT, __DS_ALIVE, etc and then have > devinfo.h and bus.h map those in, but that still wouldn't totally > solve the problem). What I would like to do is simply to typedef the enum I get from the _bus.h. I'm not sure if nothing else is still required. > : > Also, DS_BUSY is used in many drivers to PREVENT detaching. So the > : > change is bad from that point of view, since DS_DETACHING is now > > : > DS_BUSY. There's really a partial ordering relationship now where > : > before there was a total ordering (DS_BUSY is > DS_ATTACHED and > : > DS_DETACHING is > DS_ATTACH, but DS_DETACHING isn't > DS_BUSY and > : > DS_BUSY isn't > DS_DETACHING). I think that you've destroyed > : > information here by unconditionally setting it: > : > > : > - if ((error = DEVICE_DETACH(dev)) != 0) > : > + dev->state = DS_DETACHING; > : > + if ((error = DEVICE_DETACH(dev)) != 0) { > : > + KASSERT(dev->state == DS_DETACHING, > : > + ("%s: %p device state must not been changing", __func__, > : > + dev)); > : > + dev->state = DS_ATTACHED; > : > return (error); > : > + } > : > + KASSERT(dev->state == DS_DETACHING, > : > + ("%s: %p device state must not been changing", __func__, dev)); > : > > : > And this looks racy between the check earlier and this setting. > : > Properly locked, this wouldn't destroy information... > : > : Sorry, I really don't understand what point are you making here, and > : what the scaring words of "destroying", "racy", etc. means. Can you > : explain better that part? > > I think it is a minor concern. There's no locking now to prevent > multiple threads doing stuff. I think it would be better to > completely omit this stuff than to put it in 1/2 way. The point for this change is to add now parts which could introduce, in the future, ABI compatibility breakage so that we can MFC the newbus locking to 8.1. Obviously that is not a finished patch, because it still misses of the full context. > : > At the very least cardbus/cardbus.c and pccard/pccard.c need to be > : > looked at since they both have code that looks like: > : > > : > for (tmp = 0; tmp < numdevs; tmp++) { > : > struct cardbus_devinfo *dinfo = device_get_ivars(devlist[tmp]); > : > int status = device_get_state(devlist[tmp]); > : > > : > if (dinfo->pci.cfg.dev != devlist[tmp]) > : > device_printf(cbdev, "devinfo dev mismatch\n"); > : > if (status == DS_ATTACHED || status == DS_BUSY) > : > device_detach(devlist[tmp]); > : > cardbus_release_all_resources(cbdev, dinfo); > : > cardbus_device_destroy(dinfo); > : > device_delete_child(cbdev, devlist[tmp]); > : > pci_freecfg((struct pci_devinfo *)dinfo); > : > } > : > > : > which does ignore errors returned by device_detach for the DS_BUSY > : > case because there's not currently a good way to tell device_detach > : > that it *MUST* detach the device *NOW* without any possibility of veto > : > by the driver. The above code also isn't DS_DETACHING aware, and may > : > be wrong in the face of this new state. > : > : How DS_DETACHING can cause problems here? device_detach() simply won't > : run if the state is DS_DETACHING as expected (another thread is alredy > : detaching and there is no need for it to detach). > : Also, please note that in this case, for the state == DS_BUSY he > : device_detach() won't do anything. You can't simply skip the return > : value and anything else, but the reality is still the operation won't > : happen. > > I explained about partial ordering already. Let me try again. > > DS_BUSY isn't compatible with this definition. It would be better to > merge DS_ATTACHING and DS_DETACHING into one state, say DS_TRANSITION. > Then we'd do the attach sequence as DS_ALIVE -> DS_TRANSITION -> > DS_ATTACHED (and later DS_BUSY maybe). Then detach would go from > DS_ATTACHED -> DS_TRANSITION to tear it down. There's a strong > ordering expected in the code, and finding all the subtle places that > this extra state beyond DS_BUSY causes problems will be hard. We all agreed the one-state was the better option but it can't be done in this way because of the device_is_attached() used in the detach virtual functions. Using just one transition state will break device_is_attached() in those parts. The right fix, as pointed out in other e-mails, is to not use device_is_attached() in detach virtual functions. The better fix, in my idea would involve: - replace the device_is_attached() usage in detach virtual functions, with a more functional support - use one-state transition But that is just too much job to push in before then 8.0-REL and if that would mean to not commit a patch and make impossible a future MFC, I prefer to go with a lesser-perfect-but-still-working-approach. I'm sorry if these points weren't clear before. > In short, I think that http://people.freebsd.org/~imp/newbus-20090904 > should be committed and MFC'd. I've not addressed the devinfo > breakage yet... 404 Btw, I don't agree about removing the changes within subr_bus.c. They are harmless (KASSERT and further checks) and will help as a reminder. For the moment the only thing I still see to be fixed is devinfo. I will provide a patch before the end of the day. Attilio -- Peace can only be achieved by understanding - A. Einstein From imp at bsdimp.com Fri Sep 4 23:25:32 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Sep 4 23:25:38 2009 Subject: NEWBUS states In-Reply-To: <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> References: <3bbf2fe10909041455u552b0dbdm1708ea0a26365149@mail.gmail.com> <20090904.161634.-217944108.imp@bsdimp.com> <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> Message-ID: <20090904.172310.-1939841993.imp@bsdimp.com> In message: <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> Attilio Rao writes: : 2009/9/5 M. Warner Losh : : > [[ redirected to arch@ since too much of this discussion has been private ]] : > : > In message: <3bbf2fe10909041455u552b0dbdm1708ea0a26365149@mail.gmail.com> : > Attilio Rao writes: : > : 2009/9/4 M. Warner Losh : : > : > In message: <200909031340.n83Defkv034013@svn.freebsd.org> : > : > Attilio Rao writes: : > : > : Modified: head/sys/sys/bus.h : > : > : ============================================================================== : > : > : --- head/sys/sys/bus.h Thu Sep 3 12:41:00 2009 (r196778) : > : > : +++ head/sys/sys/bus.h Thu Sep 3 13:40:41 2009 (r196779) : > : > : @@ -52,8 +52,11 @@ struct u_businfo { : > : > : typedef enum device_state { : > : > : DS_NOTPRESENT, /**< @brief not probed or probe failed */ : > : > : DS_ALIVE, /**< @brief probe succeeded */ : > : > : + DS_ATTACHING, /**< @brief attaching is in progress */ : > : > : DS_ATTACHED, /**< @brief attach method called */ : > : > : - DS_BUSY /**< @brief device is open */ : > : > : + DS_BUSY, /**< @brief device is open */ : > : > : + DS_DETACHING /**< @brief detaching is in progress */ : > : > : + : > : > : } device_state_t; : > : > : > : > device_state_t is exported to userland via devctl. Well, that's not : > : > entirely true... It isn't used EXACTLY, but there's this in : > : > devinfo.h: : > : > : > : > /* : > : > * State of the device. : > : > */ : > : > /* XXX not sure if I want a copy here, or expose sys/bus.h */ : > : > typedef enum devinfo_state { : > : > DIS_NOTPRESENT, /* not probed or probe failed */ : > : > DIS_ALIVE, /* probe succeeded */ : > : > DIS_ATTACHED, /* attach method called */ : > : > DIS_BUSY /* device is open */ : > : > } devinfo_state_t; : > : > : > : > which is why devinfo is broken. : > : : > : I think the right fix here is to maintain in sync devinfo.h and bus.h : > : definition by just having one. I see that the devices states are : > : redefined in devinfo.h in order to avoid namespace pollution and this : > : is a good point. What I propose is to add a new header (_bus.h, to be : > : included in both bus.h and devinfo.h) which just containst the device : > : states. : > : > There's a lot of possible fixes. It is broken right now. Your commit : > broke it. : > : > The problem is that we have multiple names for the same things, and : > that's a defined API/ABI today.... So having a _bus.h won't solve : > this problem without introducing name space pollution (well, I suppose : > you could have __DS_NOTPRESENT, __DS_ALIVE, etc and then have : > devinfo.h and bus.h map those in, but that still wouldn't totally : > solve the problem). : : What I would like to do is simply to typedef the enum I get from the : _bus.h. I'm not sure if nothing else is still required. You can't do just that. There's the "DIS_foo vs DS_foo" issue as well, which cannot be solved with typedefs. Some mapping is required.. this is a sill API, one could argue, but it is the one we have today... : > : > Also, DS_BUSY is used in many drivers to PREVENT detaching. So the : > : > change is bad from that point of view, since DS_DETACHING is now > : > : > DS_BUSY. There's really a partial ordering relationship now where : > : > before there was a total ordering (DS_BUSY is > DS_ATTACHED and : > : > DS_DETACHING is > DS_ATTACH, but DS_DETACHING isn't > DS_BUSY and : > : > DS_BUSY isn't > DS_DETACHING). I think that you've destroyed : > : > information here by unconditionally setting it: : > : > : > : > - if ((error = DEVICE_DETACH(dev)) != 0) : > : > + dev->state = DS_DETACHING; : > : > + if ((error = DEVICE_DETACH(dev)) != 0) { : > : > + KASSERT(dev->state == DS_DETACHING, : > : > + ("%s: %p device state must not been changing", __func__, : > : > + dev)); : > : > + dev->state = DS_ATTACHED; : > : > return (error); : > : > + } : > : > + KASSERT(dev->state == DS_DETACHING, : > : > + ("%s: %p device state must not been changing", __func__, dev)); : > : > : > : > And this looks racy between the check earlier and this setting. : > : > Properly locked, this wouldn't destroy information... : > : : > : Sorry, I really don't understand what point are you making here, and : > : what the scaring words of "destroying", "racy", etc. means. Can you : > : explain better that part? : > : > I think it is a minor concern. There's no locking now to prevent : > multiple threads doing stuff. I think it would be better to : > completely omit this stuff than to put it in 1/2 way. : : The point for this change is to add now parts which could introduce, : in the future, ABI compatibility breakage so that we can MFC the : newbus locking to 8.1. Obviously that is not a finished patch, because : it still misses of the full context. Yes. I understand that. I'm specifically suggesting that we only MFC the changes to the ABI today, and MFC the changes to the code when it is complete. : > : > At the very least cardbus/cardbus.c and pccard/pccard.c need to be : > : > looked at since they both have code that looks like: : > : > : > : > for (tmp = 0; tmp < numdevs; tmp++) { : > : > struct cardbus_devinfo *dinfo = device_get_ivars(devlist[tmp]); : > : > int status = device_get_state(devlist[tmp]); : > : > : > : > if (dinfo->pci.cfg.dev != devlist[tmp]) : > : > device_printf(cbdev, "devinfo dev mismatch\n"); : > : > if (status == DS_ATTACHED || status == DS_BUSY) : > : > device_detach(devlist[tmp]); : > : > cardbus_release_all_resources(cbdev, dinfo); : > : > cardbus_device_destroy(dinfo); : > : > device_delete_child(cbdev, devlist[tmp]); : > : > pci_freecfg((struct pci_devinfo *)dinfo); : > : > } : > : > : > : > which does ignore errors returned by device_detach for the DS_BUSY : > : > case because there's not currently a good way to tell device_detach : > : > that it *MUST* detach the device *NOW* without any possibility of veto : > : > by the driver. The above code also isn't DS_DETACHING aware, and may : > : > be wrong in the face of this new state. : > : : > : How DS_DETACHING can cause problems here? device_detach() simply won't : > : run if the state is DS_DETACHING as expected (another thread is alredy : > : detaching and there is no need for it to detach). : > : Also, please note that in this case, for the state == DS_BUSY he : > : device_detach() won't do anything. You can't simply skip the return : > : value and anything else, but the reality is still the operation won't : > : happen. : > : > I explained about partial ordering already. Let me try again. : > : > DS_BUSY isn't compatible with this definition. It would be better to : > merge DS_ATTACHING and DS_DETACHING into one state, say DS_TRANSITION. : > Then we'd do the attach sequence as DS_ALIVE -> DS_TRANSITION -> : > DS_ATTACHED (and later DS_BUSY maybe). Then detach would go from : > DS_ATTACHED -> DS_TRANSITION to tear it down. There's a strong : > ordering expected in the code, and finding all the subtle places that : > this extra state beyond DS_BUSY causes problems will be hard. : : We all agreed the one-state was the better option but it can't be done : in this way because of the device_is_attached() used in the detach : virtual functions. Using just one transition state will break : device_is_attached() in those parts. True. However, this device_is_attached stuff is fundamentally broken as it is today. I took a closer look at the typical usage, and it stands in as a proxy for 'did all the resources get allocated' and even that's just the bus_resouce* stuff... : The right fix, as pointed out in other e-mails, is to not use e-mails that I wasn't cc'd on since this discussion happened in private. I hate to keep harping on this point, but there's been too much of that lately... : device_is_attached() in detach virtual functions. The better fix, in : my idea would involve: : - replace the device_is_attached() usage in detach virtual functions, : with a more functional support This would be transitioning to using a common set of code for release_resources, ala the other most common driver idiom... : - use one-state transition : : But that is just too much job to push in before then 8.0-REL and if : that would mean to not commit a patch and make impossible a future : MFC, I prefer to go with a lesser-perfect-but-still-working-approach. Yes. The problem is that we're trying to guess what the right locking approach will be at the 11th hour, and I'm worried we will guess wrong. : I'm sorry if these points weren't clear before. OK. Let me ponder based on that... It might be better for this round of changes to leverage off the device 'flags' field to indicate that we're attaching/detaching. This would not break the device_is_attached() usage, and would solve the interlock problem nicely. While it isn't as aesthetically pleasing as the new states, it would allow us to easily MFC it without API/ABI breakage. This field surely would be covered by the same set of locks as the state field. I know that there's a good aesthetic argument to be made against this, but on the other hand 'compatibility' hacks can violate one's aesthetics. We can migrate to a more pleasing state-based model in 9 and reduce the risk to other code from changing its semantics at this late date. : > In short, I think that http://people.freebsd.org/~imp/newbus-20090904 : > should be committed and MFC'd. I've not addressed the devinfo : > breakage yet... : : 404 http://people.freebsd.org/~imp/newbus-20090904.diff sorry about that... : Btw, I don't agree about removing the changes within subr_bus.c. They : are harmless (KASSERT and further checks) : and will help as a reminder. Why have them at all? We're just speculating about what the protocol will be, rather than abstracting down from a known-to-be-good implementation. This sort of thing has bit us in the past before. Since at best we're speculating about what the best approach is, I'd prefer to keep the leaps of faith as small as possible. : For the moment the only thing I still see to be fixed is devinfo. I : will provide a patch before the end of the day. Well, and getting agreement on the model that will be used for the state machine... We're not there yet... There may also be some breakage from this change that's hidden, and I need to carefully audit all uses of the state field, as well as functions that expose its state to the rest of the kernel... Warner From imp at bsdimp.com Sat Sep 5 08:36:28 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Sep 5 08:36:34 2009 Subject: NEWBUS states In-Reply-To: <20090904.172310.-1939841993.imp@bsdimp.com> References: <20090904.161634.-217944108.imp@bsdimp.com> <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> <20090904.172310.-1939841993.imp@bsdimp.com> Message-ID: <20090905.023634.831786645.imp@bsdimp.com> In message: <20090904.172310.-1939841993.imp@bsdimp.com> "M. Warner Losh" writes: : OK. Let me ponder based on that... It might be better for this round : of changes to leverage off the device 'flags' field to indicate that : we're attaching/detaching. This would not break the : device_is_attached() usage, and would solve the interlock problem : nicely. While it isn't as aesthetically pleasing as the new states, : it would allow us to easily MFC it without API/ABI breakage. This : field surely would be covered by the same set of locks as the state : field. : : I know that there's a good aesthetic argument to be made against this, : but on the other hand 'compatibility' hacks can violate one's : aesthetics. We can migrate to a more pleasing state-based model in 9 : and reduce the risk to other code from changing its semantics at this : late date. For a version of this hack, see http://people.freebsd.org/~imp/newbus-flags.diff This preserves the semantics of the state field as they exist today, while also providing protection against reentrent code. It also restores a check for GIANT_HELD to the attach routine, which seems to have disappeared along the way. While not needed when the locking does arrive, it is needed today, I believe. It also has the advantage that the following could easily be added to catch wayward drivers: int device_is_attached(device_t dev) { if (dev->flags & DF_TRANSITION) printf( "%s called %s while in attach/detach. This is no deprecated.", device_get_nameunit(dev), __func__); return (dev->state >= DS_ATTACHED); } Or make it a KASSERT later in the 9.x release cycle. Hope this make it clear what my proposed alternative would be... Warner P.S. Yes, I'd rate this code as speculative as the code it replaces (see my prior posts for this criticism). This is an example of how it could be done with less impact to the existing code base, a consideration only because we're in the high 50's of minutes in the 11th hour for the 8.0 release... From attilio at freebsd.org Sat Sep 5 15:12:19 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Sep 5 15:12:26 2009 Subject: NEWBUS states In-Reply-To: <20090904.172310.-1939841993.imp@bsdimp.com> References: <3bbf2fe10909041455u552b0dbdm1708ea0a26365149@mail.gmail.com> <20090904.161634.-217944108.imp@bsdimp.com> <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> <20090904.172310.-1939841993.imp@bsdimp.com> Message-ID: <3bbf2fe10909050812l4340f679h6a4d7dae1daa3bf8@mail.gmail.com> 2009/9/5 M. Warner Losh : > In message: <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> > Attilio Rao writes: > : 2009/9/5 M. Warner Losh : > : > [[ redirected to arch@ since too much of this discussion has been private ]] > : > > : > In message: <3bbf2fe10909041455u552b0dbdm1708ea0a26365149@mail.gmail.com> > : > Attilio Rao writes: > : > : 2009/9/4 M. Warner Losh : > : > : > In message: <200909031340.n83Defkv034013@svn.freebsd.org> > : > : > Attilio Rao writes: > : > : > : Modified: head/sys/sys/bus.h > : > : > : ============================================================================== > : > : > : --- head/sys/sys/bus.h Thu Sep 3 12:41:00 2009 (r196778) > : > : > : +++ head/sys/sys/bus.h Thu Sep 3 13:40:41 2009 (r196779) > : > : > : @@ -52,8 +52,11 @@ struct u_businfo { > : > : > : typedef enum device_state { > : > : > : DS_NOTPRESENT, /**< @brief not probed or probe failed */ > : > : > : DS_ALIVE, /**< @brief probe succeeded */ > : > : > : + DS_ATTACHING, /**< @brief attaching is in progress */ > : > : > : DS_ATTACHED, /**< @brief attach method called */ > : > : > : - DS_BUSY /**< @brief device is open */ > : > : > : + DS_BUSY, /**< @brief device is open */ > : > : > : + DS_DETACHING /**< @brief detaching is in progress */ > : > : > : + > : > : > : } device_state_t; > : > : > > : > : > device_state_t is exported to userland via devctl. Well, that's not > : > : > entirely true... It isn't used EXACTLY, but there's this in > : > : > devinfo.h: > : > : > > : > : > /* > : > : > * State of the device. > : > : > */ > : > : > /* XXX not sure if I want a copy here, or expose sys/bus.h */ > : > : > typedef enum devinfo_state { > : > : > DIS_NOTPRESENT, /* not probed or probe failed */ > : > : > DIS_ALIVE, /* probe succeeded */ > : > : > DIS_ATTACHED, /* attach method called */ > : > : > DIS_BUSY /* device is open */ > : > : > } devinfo_state_t; > : > : > > : > : > which is why devinfo is broken. > : > : > : > : I think the right fix here is to maintain in sync devinfo.h and bus.h > : > : definition by just having one. I see that the devices states are > : > : redefined in devinfo.h in order to avoid namespace pollution and this > : > : is a good point. What I propose is to add a new header (_bus.h, to be > : > : included in both bus.h and devinfo.h) which just containst the device > : > : states. > : > > : > There's a lot of possible fixes. It is broken right now. Your commit > : > broke it. > : > > : > The problem is that we have multiple names for the same things, and > : > that's a defined API/ABI today.... So having a _bus.h won't solve > : > this problem without introducing name space pollution (well, I suppose > : > you could have __DS_NOTPRESENT, __DS_ALIVE, etc and then have > : > devinfo.h and bus.h map those in, but that still wouldn't totally > : > solve the problem). > : > : What I would like to do is simply to typedef the enum I get from the > : _bus.h. I'm not sure if nothing else is still required. > > You can't do just that. There's the "DIS_foo vs DS_foo" issue as > well, which cannot be solved with typedefs. Some mapping is > required.. this is a sill API, one could argue, but it is the one we > have today... Bah, sorry, I kept reading it as DS_ rather than DIS_ . Anyways, what do you think about, for 9.0, just having one interface and remove the DIS_* bloat? > : > : The point for this change is to add now parts which could introduce, > : in the future, ABI compatibility breakage so that we can MFC the > : newbus locking to 8.1. Obviously that is not a finished patch, because > : it still misses of the full context. > > Yes. I understand that. I'm specifically suggesting that we only MFC > the changes to the ABI today, and MFC the changes to the code when it > is complete. Sure, and that's what I did. The small parts in subr_bus.c aren't that much important but they can be used as a reminder. If you feel strongly against it I can also review and eventually drop them. > : We all agreed the one-state was the better option but it can't be done > : in this way because of the device_is_attached() used in the detach > : virtual functions. Using just one transition state will break > : device_is_attached() in those parts. > > True. However, this device_is_attached stuff is fundamentally broken > as it is today. I took a closer look at the typical usage, and it > stands in as a proxy for 'did all the resources get allocated' and > even that's just the bus_resouce* stuff... Of course. Such paradigms are only sane (in particular from the standpoint of the locking) only when you can make some assumptions about a known context, and you should also know the state of your device there. > : The right fix, as pointed out in other e-mails, is to not use > > e-mails that I wasn't cc'd on since this discussion happened in > private. I hate to keep harping on this point, but there's been too > much of that lately... Sorry for that, but in this case I was referring to e-mail sent to public mailing list. My current english and expressive skillset is not that much developed so far though, so it is likely I did express the concept with cryptic/incorrect words as often happens, so I can't blame anyone else than me for that. > : device_is_attached() in detach virtual functions. The better fix, in > : my idea would involve: > : - replace the device_is_attached() usage in detach virtual functions, > : with a more functional support > > This would be transitioning to using a common set of code for > release_resources, ala the other most common driver idiom... I agree. There are various ways to fix this that we can discuss and put in place during 9.0 timelife. > : - use one-state transition > : > : But that is just too much job to push in before then 8.0-REL and if > : that would mean to not commit a patch and make impossible a future > : MFC, I prefer to go with a lesser-perfect-but-still-working-approach. > > Yes. The problem is that we're trying to guess what the right locking > approach will be at the 11th hour, and I'm worried we will guess wrong. > > : I'm sorry if these points weren't clear before. > > OK. Let me ponder based on that... It might be better for this round > of changes to leverage off the device 'flags' field to indicate that > we're attaching/detaching. This would not break the > device_is_attached() usage, and would solve the interlock problem > nicely. While it isn't as aesthetically pleasing as the new states, > it would allow us to easily MFC it without API/ABI breakage. This > field surely would be covered by the same set of locks as the state > field. > > I know that there's a good aesthetic argument to be made against this, > but on the other hand 'compatibility' hacks can violate one's > aesthetics. We can migrate to a more pleasing state-based model in 9 > and reduce the risk to other code from changing its semantics at this > late date. That was exactly the original point of my commit. > : > In short, I think that http://people.freebsd.org/~imp/newbus-20090904 > : > should be committed and MFC'd. I've not addressed the devinfo > : > breakage yet... > : > : 404 > > http://people.freebsd.org/~imp/newbus-20090904.diff > > sorry about that... So I see in this patch you are also implementing the idea to offer rooms in the enum intra-existing-states that kib proposed. That is a good idea to do now. However, the one-state transition can't be implemented in this patch as you accepted few lines above. > : Btw, I don't agree about removing the changes within subr_bus.c. They > : are harmless (KASSERT and further checks) > : and will help as a reminder. > > Why have them at all? We're just speculating about what the protocol > will be, rather than abstracting down from a known-to-be-good > implementation. This sort of thing has bit us in the past before. > Since at best we're speculating about what the best approach is, I'd > prefer to keep the leaps of faith as small as possible. Ok, if you are strongly against it, we can remove them, I just think they will be harmless and a good reminder. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From attilio at freebsd.org Sat Sep 5 15:17:57 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Sep 5 15:18:03 2009 Subject: NEWBUS states In-Reply-To: <20090905.023634.831786645.imp@bsdimp.com> References: <20090904.161634.-217944108.imp@bsdimp.com> <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> <20090904.172310.-1939841993.imp@bsdimp.com> <20090905.023634.831786645.imp@bsdimp.com> Message-ID: <3bbf2fe10909050817w4e8da3adxd8e431749b432070@mail.gmail.com> 2009/9/5 M. Warner Losh : > In message: <20090904.172310.-1939841993.imp@bsdimp.com> > "M. Warner Losh" writes: > : OK. Let me ponder based on that... It might be better for this round > : of changes to leverage off the device 'flags' field to indicate that > : we're attaching/detaching. This would not break the > : device_is_attached() usage, and would solve the interlock problem > : nicely. While it isn't as aesthetically pleasing as the new states, > : it would allow us to easily MFC it without API/ABI breakage. This > : field surely would be covered by the same set of locks as the state > : field. > : > : I know that there's a good aesthetic argument to be made against this, > : but on the other hand 'compatibility' hacks can violate one's > : aesthetics. We can migrate to a more pleasing state-based model in 9 > : and reduce the risk to other code from changing its semantics at this > : late date. > > For a version of this hack, see > http://people.freebsd.org/~imp/newbus-flags.diff So you propose to offer the transition on the device flags instead than the device states? That is an interesting approach mostly because it won't require an ABI breakage, but let me think about locking implications with it as I want to review some code and came up with a patch/thoughts in some hours. Attilio -- Peace can only be achieved by understanding - A. Einstein From imp at bsdimp.com Sat Sep 5 15:30:28 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Sep 5 15:31:58 2009 Subject: NEWBUS states In-Reply-To: <3bbf2fe10909050817w4e8da3adxd8e431749b432070@mail.gmail.com> References: <20090904.172310.-1939841993.imp@bsdimp.com> <20090905.023634.831786645.imp@bsdimp.com> <3bbf2fe10909050817w4e8da3adxd8e431749b432070@mail.gmail.com> Message-ID: <20090905.093037.1927920092.imp@bsdimp.com> In message: <3bbf2fe10909050817w4e8da3adxd8e431749b432070@mail.gmail.com> Attilio Rao writes: : 2009/9/5 M. Warner Losh : : > In message: <20090904.172310.-1939841993.imp@bsdimp.com> : > "M. Warner Losh" writes: : > : OK. Let me ponder based on that... It might be better for this round : > : of changes to leverage off the device 'flags' field to indicate that : > : we're attaching/detaching. This would not break the : > : device_is_attached() usage, and would solve the interlock problem : > : nicely. While it isn't as aesthetically pleasing as the new states, : > : it would allow us to easily MFC it without API/ABI breakage. This : > : field surely would be covered by the same set of locks as the state : > : field. : > : : > : I know that there's a good aesthetic argument to be made against this, : > : but on the other hand 'compatibility' hacks can violate one's : > : aesthetics. We can migrate to a more pleasing state-based model in 9 : > : and reduce the risk to other code from changing its semantics at this : > : late date. : > : > For a version of this hack, see : > http://people.freebsd.org/~imp/newbus-flags.diff : : So you propose to offer the transition on the device flags instead : than the device states? : That is an interesting approach mostly because it won't require an ABI : breakage, but let me think about locking implications with it as I : want to review some code and came up with a patch/thoughts in some : hours. Please do. I wanted this to provoke thought and experimentation. While not the most beautiful approach, it is one that we can use to get around the API/ABI issues. Please let me know how it works out... The assumption in the patch is that locking requirements for state and flags are identical... Warner From imp at bsdimp.com Sat Sep 5 17:15:28 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Sep 5 17:15:34 2009 Subject: NEWBUS states In-Reply-To: <3bbf2fe10909050812l4340f679h6a4d7dae1daa3bf8@mail.gmail.com> References: <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> <20090904.172310.-1939841993.imp@bsdimp.com> <3bbf2fe10909050812l4340f679h6a4d7dae1daa3bf8@mail.gmail.com> Message-ID: <20090905.111446.500055027.imp@bsdimp.com> Attilio, [[ trimmed ]] Sounds like we're getting closer to closure... In message: <3bbf2fe10909050812l4340f679h6a4d7dae1daa3bf8@mail.gmail.com> Attilio Rao writes: : Bah, sorry, I kept reading it as DS_ rather than DIS_ . : Anyways, what do you think about, for 9.0, just having one interface : and remove the DIS_* bloat? [ disconnect between libdevinfo and kernel types ] I think we should have both for either 8.x or 9.x (depending on what the RE@ will permit), and then drop the DIS_ the next release after that. : Ok, if you are strongly against it, we can remove them, I just think : they will be harmless and a good reminder. [ Have the code there to document/enforce protocol wrt state ] I think I'd prefer not to have it, but could easily allow it if we know that it causes no harm and can be reasonably sure that it is close to what the final protocol will be. Warner From wollman at hergotha.csail.mit.edu Mon Sep 7 05:43:16 2009 From: wollman at hergotha.csail.mit.edu (Garrett Wollman) Date: Mon Sep 7 05:43:23 2009 Subject: incorrect usleep/select delays with HZ > 2500 In-Reply-To: <20090906155154.GA8283@onelab2.iet.unipi.it> Message-ID: <200909070515.n875Fct3048327@hergotha.csail.mit.edu> In article <20090906155154.GA8283@onelab2.iet.unipi.it> you write: >(this problem seems to affect both current and -stable, >so let's see if here i have better luck) > >I just noticed [Note 1,2] that when setting HZ > 2500 (even if it is >an exact divisor of the APIC/CPU clock) there is a significant >drift between the delays generated by usleep()/select() and those >computed by gettimeofday(). In other words, the error grows with >the amount of delay requested. If I may be so bold as to suggest: if you think you want HZ > 1000, you're probably wrong. -GAWollman -- Garrett A. Wollman | What intellectual phenomenon can be older, or more oft wollman@bimajority.org| repeated, than the story of a large research program Opinions not shared by| that impaled itself upon a false central assumption my employers. | accepted by all practitioners? - S.J. Gould, 1993 From bugmaster at FreeBSD.org Mon Sep 7 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 7 11:07:20 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200909071106.n87B6s6f010141@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From jhb at freebsd.org Tue Sep 8 13:38:00 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Sep 8 13:38:12 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> References: <200909031340.n83Defkv034013@svn.freebsd.org> <20090904.161634.-217944108.imp@bsdimp.com> <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> Message-ID: <200909080936.37603.jhb@freebsd.org> On Friday 04 September 2009 6:46:03 pm Attilio Rao wrote: > We all agreed the one-state was the better option but it can't be done > in this way because of the device_is_attached() used in the detach > virtual functions. Using just one transition state will break > device_is_attached() in those parts. > The right fix, as pointed out in other e-mails, is to not use > device_is_attached() in detach virtual functions. The better fix, in > my idea would involve: > - replace the device_is_attached() usage in detach virtual functions, > with a more functional support > - use one-state transition > > But that is just too much job to push in before then 8.0-REL and if > that would mean to not commit a patch and make impossible a future > MFC, I prefer to go with a lesser-perfect-but-still-working-approach. Wait, all you need to MFC is the change to the enum. Fixing the various detach routines does _not_ have to be in 8.0. That could be merged after the release. -- John Baldwin From jhb at freebsd.org Tue Sep 8 13:38:00 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Sep 8 13:38:12 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> References: <200909031340.n83Defkv034013@svn.freebsd.org> <20090904.161634.-217944108.imp@bsdimp.com> <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> Message-ID: <200909080936.37603.jhb@freebsd.org> On Friday 04 September 2009 6:46:03 pm Attilio Rao wrote: > We all agreed the one-state was the better option but it can't be done > in this way because of the device_is_attached() used in the detach > virtual functions. Using just one transition state will break > device_is_attached() in those parts. > The right fix, as pointed out in other e-mails, is to not use > device_is_attached() in detach virtual functions. The better fix, in > my idea would involve: > - replace the device_is_attached() usage in detach virtual functions, > with a more functional support > - use one-state transition > > But that is just too much job to push in before then 8.0-REL and if > that would mean to not commit a patch and make impossible a future > MFC, I prefer to go with a lesser-perfect-but-still-working-approach. Wait, all you need to MFC is the change to the enum. Fixing the various detach routines does _not_ have to be in 8.0. That could be merged after the release. -- John Baldwin From attilio at freebsd.org Wed Sep 9 09:39:41 2009 From: attilio at freebsd.org (Attilio Rao) Date: Wed Sep 9 09:39:52 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <200909080936.37603.jhb@freebsd.org> References: <200909031340.n83Defkv034013@svn.freebsd.org> <20090904.161634.-217944108.imp@bsdimp.com> <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> <200909080936.37603.jhb@freebsd.org> Message-ID: <3bbf2fe10909090239r519ae737t56ddd7ca36e5f84d@mail.gmail.com> 2009/9/8 John Baldwin : > On Friday 04 September 2009 6:46:03 pm Attilio Rao wrote: >> We all agreed the one-state was the better option but it can't be done >> in this way because of the device_is_attached() used in the detach >> virtual functions. Using just one transition state will break >> device_is_attached() in those parts. >> The right fix, as pointed out in other e-mails, is to not use >> device_is_attached() in detach virtual functions. The better fix, in >> my idea would involve: >> - replace the device_is_attached() usage in detach virtual functions, >> with a more functional support >> - use one-state transition >> >> But that is just too much job to push in before then 8.0-REL and if >> that would mean to not commit a patch and make impossible a future >> MFC, I prefer to go with a lesser-perfect-but-still-working-approach. > > Wait, all you need to MFC is the change to the enum. Fixing the various > detach routines does _not_ have to be in 8.0. That could be merged after the > release. That's not what I mean. What I mean is that in order to have a perfect job right now (and have single-state transition usable *right now* by both STABLE_8 and HEAD) that what should happen, which is impractical. I was just explaining to Warner why we didn't go with the single-state in the end. Attilio -- Peace can only be achieved by understanding - A. Einstein From attilio at freebsd.org Wed Sep 9 09:39:41 2009 From: attilio at freebsd.org (Attilio Rao) Date: Wed Sep 9 09:39:53 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <200909080936.37603.jhb@freebsd.org> References: <200909031340.n83Defkv034013@svn.freebsd.org> <20090904.161634.-217944108.imp@bsdimp.com> <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> <200909080936.37603.jhb@freebsd.org> Message-ID: <3bbf2fe10909090239r519ae737t56ddd7ca36e5f84d@mail.gmail.com> 2009/9/8 John Baldwin : > On Friday 04 September 2009 6:46:03 pm Attilio Rao wrote: >> We all agreed the one-state was the better option but it can't be done >> in this way because of the device_is_attached() used in the detach >> virtual functions. Using just one transition state will break >> device_is_attached() in those parts. >> The right fix, as pointed out in other e-mails, is to not use >> device_is_attached() in detach virtual functions. The better fix, in >> my idea would involve: >> - replace the device_is_attached() usage in detach virtual functions, >> with a more functional support >> - use one-state transition >> >> But that is just too much job to push in before then 8.0-REL and if >> that would mean to not commit a patch and make impossible a future >> MFC, I prefer to go with a lesser-perfect-but-still-working-approach. > > Wait, all you need to MFC is the change to the enum. Fixing the various > detach routines does _not_ have to be in 8.0. That could be merged after the > release. That's not what I mean. What I mean is that in order to have a perfect job right now (and have single-state transition usable *right now* by both STABLE_8 and HEAD) that what should happen, which is impractical. I was just explaining to Warner why we didn't go with the single-state in the end. Attilio -- Peace can only be achieved by understanding - A. Einstein From jhb at freebsd.org Wed Sep 9 17:16:35 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 9 17:16:50 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <3bbf2fe10909090239r519ae737t56ddd7ca36e5f84d@mail.gmail.com> References: <200909031340.n83Defkv034013@svn.freebsd.org> <200909080936.37603.jhb@freebsd.org> <3bbf2fe10909090239r519ae737t56ddd7ca36e5f84d@mail.gmail.com> Message-ID: <200909091316.28063.jhb@freebsd.org> On Wednesday 09 September 2009 5:39:39 am Attilio Rao wrote: > 2009/9/8 John Baldwin : > > On Friday 04 September 2009 6:46:03 pm Attilio Rao wrote: > >> We all agreed the one-state was the better option but it can't be done > >> in this way because of the device_is_attached() used in the detach > >> virtual functions. Using just one transition state will break > >> device_is_attached() in those parts. > >> The right fix, as pointed out in other e-mails, is to not use > >> device_is_attached() in detach virtual functions. The better fix, in > >> my idea would involve: > >> - replace the device_is_attached() usage in detach virtual functions, > >> with a more functional support > >> - use one-state transition > >> > >> But that is just too much job to push in before then 8.0-REL and if > >> that would mean to not commit a patch and make impossible a future > >> MFC, I prefer to go with a lesser-perfect-but-still-working-approach. > > > > Wait, all you need to MFC is the change to the enum. Fixing the various > > detach routines does _not_ have to be in 8.0. That could be merged after the > > release. > > That's not what I mean. > What I mean is that in order to have a perfect job right now (and have > single-state transition usable *right now* by both STABLE_8 and HEAD) > that what should happen, which is impractical. > I was just explaining to Warner why we didn't go with the single-state > in the end. But we don't need it usable right now. All you need for 8.0 is to reserve the slot in the enum so that the ABI of the enum values doesn't change. Making the state usable is something that can happen after the release and it can include all the changes to make the single state usable. -- John Baldwin From jhb at freebsd.org Wed Sep 9 17:16:35 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 9 17:16:50 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <3bbf2fe10909090239r519ae737t56ddd7ca36e5f84d@mail.gmail.com> References: <200909031340.n83Defkv034013@svn.freebsd.org> <200909080936.37603.jhb@freebsd.org> <3bbf2fe10909090239r519ae737t56ddd7ca36e5f84d@mail.gmail.com> Message-ID: <200909091316.28063.jhb@freebsd.org> On Wednesday 09 September 2009 5:39:39 am Attilio Rao wrote: > 2009/9/8 John Baldwin : > > On Friday 04 September 2009 6:46:03 pm Attilio Rao wrote: > >> We all agreed the one-state was the better option but it can't be done > >> in this way because of the device_is_attached() used in the detach > >> virtual functions. Using just one transition state will break > >> device_is_attached() in those parts. > >> The right fix, as pointed out in other e-mails, is to not use > >> device_is_attached() in detach virtual functions. The better fix, in > >> my idea would involve: > >> - replace the device_is_attached() usage in detach virtual functions, > >> with a more functional support > >> - use one-state transition > >> > >> But that is just too much job to push in before then 8.0-REL and if > >> that would mean to not commit a patch and make impossible a future > >> MFC, I prefer to go with a lesser-perfect-but-still-working-approach. > > > > Wait, all you need to MFC is the change to the enum. Fixing the various > > detach routines does _not_ have to be in 8.0. That could be merged after the > > release. > > That's not what I mean. > What I mean is that in order to have a perfect job right now (and have > single-state transition usable *right now* by both STABLE_8 and HEAD) > that what should happen, which is impractical. > I was just explaining to Warner why we didn't go with the single-state > in the end. But we don't need it usable right now. All you need for 8.0 is to reserve the slot in the enum so that the ABI of the enum values doesn't change. Making the state usable is something that can happen after the release and it can include all the changes to make the single state usable. -- John Baldwin From mailing at ekomedya.com Thu Sep 10 15:18:52 2009 From: mailing at ekomedya.com (=?utf-8?Q?Eko_Bilgisayar_ve_=C4=B0leti=C5=9Fim_Hizmetleri_Ltd=2E_=C5=9Eti?=) Date: Thu Sep 10 15:20:38 2009 Subject: Turkey Calling You To Visit - The Trade SHOW- In Las Vegas Message-ID: <95f2ee93cb941b73f5c005c2f883c20f@localhost.localdomain> [http://www.turkeycalling.us] [http://www.turkeycalling.us] [http://www.turkeycalling.us] [http://www.turkeycalling.us/turkey-fam/turkeyfam.htm] Global Access Travel invites you to the Tradeshow in Las Vegas on September 13-15, 2009. Please visit us to get more information about our organization and services at our booth. If you fill the registration form or leave the business card when you visit us at our booth, you might be lucky visitor who is going to win our daily draw prize; Free inspection trip to Turkey. Yasal Uyar?; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ?c?nc? kisiler ile paylasilmasi m?mk?n olmayabilir.Mesaji alan kisi, mesajin g?nderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa l?tfen mesaji geri g?nderiniz ve sisteminizden siliniz. Global Access Travel bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez Disclaimer This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Access Traveldoes not accept legal responsibility for the contents of this message. Yasal Uyar?; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ?c?nc? kisiler ile paylasilmasi m?mk?n olmayabilir.Mesaji alan kisi, mesajin g?nderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa l?tfen mesaji geri g?nderiniz ve sisteminizden siliniz. Global Access Travel bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez Disclaimer This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Access Traveldoes not accept legal responsibility for the contents of this message. Yasal Uyar?; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ?c?nc? kisiler ile paylasilmasi m?mk?n olmayabilir.Mesaji alan kisi, mesajin g?nderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa l?tfen mesaji geri g?nderiniz ve sisteminizden siliniz. Global Access Travel bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez Disclaimer This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Access Traveldoes not accept legal responsibility for the contents of this message. This message was sent by: TURKEY CALLING YOU TO VISIT "THE TRADE SHOW" IN LAS VEGAS, N?zhetiye Cad, istanbul, Besiktas 34357, Turkey Manage your subscription: http://app.icontact.com/icp/mmail-mprofile.pl?r=47622541&l=82253&s=KL6W&m=587775&c=305227 From hselasky at c2i.net Sat Sep 12 09:09:05 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Sep 12 09:09:17 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <200909080936.37603.jhb@freebsd.org> References: <200909031340.n83Defkv034013@svn.freebsd.org> <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> <200909080936.37603.jhb@freebsd.org> Message-ID: <200909121009.22931.hselasky@c2i.net> On Tuesday 08 September 2009 15:36:37 John Baldwin wrote: > On Friday 04 September 2009 6:46:03 pm Attilio Rao wrote: > > We all agreed the one-state was the better option but it can't be done > > in this way because of the device_is_attached() used in the detach > > virtual functions. Using just one transition state will break > > device_is_attached() in those parts. > > The right fix, as pointed out in other e-mails, is to not use > > device_is_attached() in detach virtual functions. The better fix, in > > my idea would involve: > > - replace the device_is_attached() usage in detach virtual functions, > > with a more functional support > > - use one-state transition > > > > But that is just too much job to push in before then 8.0-REL and if > > that would mean to not commit a patch and make impossible a future > > MFC, I prefer to go with a lesser-perfect-but-still-working-approach. > > Wait, all you need to MFC is the change to the enum. Fixing the various > detach routines does _not_ have to be in 8.0. That could be merged after > the release. Hi, http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_bus.c?r1=196529&r2=196779 I'm sorry to say that the latest patches to subr_bus.c have broken USB. I've got several reports on memory used after free, due to bus_generic_detach() returning EBUSY when called from uhub_detach(). ... bus_generic_detach(device_t dev) { device_t child; int error; if (dev->state != DS_ATTACHED) return (EBUSY); TAILQ_FOREACH(child, &dev->children, link) { if ((error = device_detach(child)) != 0) return (error); } return (0); } A fix for USB is available here: http://perforce.freebsd.org/chv.cgi?CH=168387 --HPS From hselasky at c2i.net Sat Sep 12 09:09:05 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Sep 12 09:09:18 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <200909080936.37603.jhb@freebsd.org> References: <200909031340.n83Defkv034013@svn.freebsd.org> <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> <200909080936.37603.jhb@freebsd.org> Message-ID: <200909121009.22931.hselasky@c2i.net> On Tuesday 08 September 2009 15:36:37 John Baldwin wrote: > On Friday 04 September 2009 6:46:03 pm Attilio Rao wrote: > > We all agreed the one-state was the better option but it can't be done > > in this way because of the device_is_attached() used in the detach > > virtual functions. Using just one transition state will break > > device_is_attached() in those parts. > > The right fix, as pointed out in other e-mails, is to not use > > device_is_attached() in detach virtual functions. The better fix, in > > my idea would involve: > > - replace the device_is_attached() usage in detach virtual functions, > > with a more functional support > > - use one-state transition > > > > But that is just too much job to push in before then 8.0-REL and if > > that would mean to not commit a patch and make impossible a future > > MFC, I prefer to go with a lesser-perfect-but-still-working-approach. > > Wait, all you need to MFC is the change to the enum. Fixing the various > detach routines does _not_ have to be in 8.0. That could be merged after > the release. Hi, http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_bus.c?r1=196529&r2=196779 I'm sorry to say that the latest patches to subr_bus.c have broken USB. I've got several reports on memory used after free, due to bus_generic_detach() returning EBUSY when called from uhub_detach(). ... bus_generic_detach(device_t dev) { device_t child; int error; if (dev->state != DS_ATTACHED) return (EBUSY); TAILQ_FOREACH(child, &dev->children, link) { if ((error = device_detach(child)) != 0) return (error); } return (0); } A fix for USB is available here: http://perforce.freebsd.org/chv.cgi?CH=168387 --HPS From attilio at freebsd.org Sun Sep 13 15:20:43 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sun Sep 13 15:20:55 2009 Subject: NEWBUS states In-Reply-To: <20090905.111446.500055027.imp@bsdimp.com> References: <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> <20090904.172310.-1939841993.imp@bsdimp.com> <3bbf2fe10909050812l4340f679h6a4d7dae1daa3bf8@mail.gmail.com> <20090905.111446.500055027.imp@bsdimp.com> Message-ID: <3bbf2fe10909130820t62f03cfflcdf45a651db15f14@mail.gmail.com> 2009/9/5 M. Warner Losh : > Attilio, > > [[ trimmed ]] > > Sounds like we're getting closer to closure... > So I reverted r196779 and now I would like to commit and MFC just this patch: http://www.freebsd.org/~attilio/newbus9-8.diff I still think the good way to go is to use the device flags, but this patch will allow us to be highly flexible in terms of adding new states, if we need it in the future. Let me know if you have objections against that. Attilio -- Peace can only be achieved by understanding - A. Einstein From attilio at freebsd.org Sun Sep 13 15:27:25 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sun Sep 13 15:27:36 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <200909121009.22931.hselasky@c2i.net> References: <200909031340.n83Defkv034013@svn.freebsd.org> <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> <200909080936.37603.jhb@freebsd.org> <200909121009.22931.hselasky@c2i.net> Message-ID: <3bbf2fe10909130827m5d8381ebv3e7167986f1f104d@mail.gmail.com> 2009/9/12 Hans Petter Selasky : > On Tuesday 08 September 2009 15:36:37 John Baldwin wrote: >> On Friday 04 September 2009 6:46:03 pm Attilio Rao wrote: >> > We all agreed the one-state was the better option but it can't be done >> > in this way because of the device_is_attached() used in the detach >> > virtual functions. Using just one transition state will break >> > device_is_attached() in those parts. >> > The right fix, as pointed out in other e-mails, is to not use >> > device_is_attached() in detach virtual functions. The better fix, in >> > my idea would involve: >> > - replace the device_is_attached() usage in detach virtual functions, >> > with a more functional support >> > - use one-state transition >> > >> > But that is just too much job to push in before then 8.0-REL and if >> > that would mean to not commit a patch and make impossible a future >> > MFC, I prefer to go with a lesser-perfect-but-still-working-approach. >> >> Wait, all you need to MFC is the change to the enum. Fixing the various >> detach routines does _not_ have to be in 8.0. That could be merged after >> the release. > > Hi, > > http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_bus.c?r1=196529&r2=196779 > > I'm sorry to say that the latest patches to subr_bus.c have broken USB. I've > got several reports on memory used after free, due to bus_generic_detach() > returning EBUSY when called from uhub_detach(). Yes, I think there was an error in the logic. However I reverted them because we decided to go with another approach. I'm not sure if your patch (I still didn't review them) are though necessary even in the case of a saner logic, so for the moment, try to not loose them. Attilio -- Peace can only be achieved by understanding - A. Einstein From attilio at freebsd.org Sun Sep 13 15:27:25 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sun Sep 13 15:27:36 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <200909121009.22931.hselasky@c2i.net> References: <200909031340.n83Defkv034013@svn.freebsd.org> <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> <200909080936.37603.jhb@freebsd.org> <200909121009.22931.hselasky@c2i.net> Message-ID: <3bbf2fe10909130827m5d8381ebv3e7167986f1f104d@mail.gmail.com> 2009/9/12 Hans Petter Selasky : > On Tuesday 08 September 2009 15:36:37 John Baldwin wrote: >> On Friday 04 September 2009 6:46:03 pm Attilio Rao wrote: >> > We all agreed the one-state was the better option but it can't be done >> > in this way because of the device_is_attached() used in the detach >> > virtual functions. Using just one transition state will break >> > device_is_attached() in those parts. >> > The right fix, as pointed out in other e-mails, is to not use >> > device_is_attached() in detach virtual functions. The better fix, in >> > my idea would involve: >> > - replace the device_is_attached() usage in detach virtual functions, >> > with a more functional support >> > - use one-state transition >> > >> > But that is just too much job to push in before then 8.0-REL and if >> > that would mean to not commit a patch and make impossible a future >> > MFC, I prefer to go with a lesser-perfect-but-still-working-approach. >> >> Wait, all you need to MFC is the change to the enum. Fixing the various >> detach routines does _not_ have to be in 8.0. That could be merged after >> the release. > > Hi, > > http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_bus.c?r1=196529&r2=196779 > > I'm sorry to say that the latest patches to subr_bus.c have broken USB. I've > got several reports on memory used after free, due to bus_generic_detach() > returning EBUSY when called from uhub_detach(). Yes, I think there was an error in the logic. However I reverted them because we decided to go with another approach. I'm not sure if your patch (I still didn't review them) are though necessary even in the case of a saner logic, so for the moment, try to not loose them. Attilio -- Peace can only be achieved by understanding - A. Einstein From bugmaster at FreeBSD.org Mon Sep 14 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 14 11:07:27 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200909141106.n8EB6skK072242@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From jhb at freebsd.org Mon Sep 14 13:13:37 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 14 13:14:02 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <200909121009.22931.hselasky@c2i.net> References: <200909031340.n83Defkv034013@svn.freebsd.org> <200909080936.37603.jhb@freebsd.org> <200909121009.22931.hselasky@c2i.net> Message-ID: <200909140852.49192.jhb@freebsd.org> On Saturday 12 September 2009 4:09:21 am Hans Petter Selasky wrote: > On Tuesday 08 September 2009 15:36:37 John Baldwin wrote: > > On Friday 04 September 2009 6:46:03 pm Attilio Rao wrote: > > > We all agreed the one-state was the better option but it can't be done > > > in this way because of the device_is_attached() used in the detach > > > virtual functions. Using just one transition state will break > > > device_is_attached() in those parts. > > > The right fix, as pointed out in other e-mails, is to not use > > > device_is_attached() in detach virtual functions. The better fix, in > > > my idea would involve: > > > - replace the device_is_attached() usage in detach virtual functions, > > > with a more functional support > > > - use one-state transition > > > > > > But that is just too much job to push in before then 8.0-REL and if > > > that would mean to not commit a patch and make impossible a future > > > MFC, I prefer to go with a lesser-perfect-but-still-working-approach. > > > > Wait, all you need to MFC is the change to the enum. Fixing the various > > detach routines does _not_ have to be in 8.0. That could be merged after > > the release. > > Hi, > > http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_bus.c?r1=196529&r2=196779 > > I'm sorry to say that the latest patches to subr_bus.c have broken USB. I've > got several reports on memory used after free, due to bus_generic_detach() > returning EBUSY when called from uhub_detach(). > > ... > bus_generic_detach(device_t dev) > { > device_t child; > int error; > > if (dev->state != DS_ATTACHED) > return (EBUSY); > > TAILQ_FOREACH(child, &dev->children, link) { > if ((error = device_detach(child)) != 0) > return (error); > } > > return (0); > } > > A fix for USB is available here: > > http://perforce.freebsd.org/chv.cgi?CH=168387 I think bus_generic_detach() needs to work when called from a foo_detach() routine, so I think you don't need the USB changes. Even if the new states get reintroduced bus_generic_detach() will still have to work correctly the way you had used it. -- John Baldwin From jhb at freebsd.org Mon Sep 14 13:13:37 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 14 13:14:02 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <200909121009.22931.hselasky@c2i.net> References: <200909031340.n83Defkv034013@svn.freebsd.org> <200909080936.37603.jhb@freebsd.org> <200909121009.22931.hselasky@c2i.net> Message-ID: <200909140852.49192.jhb@freebsd.org> On Saturday 12 September 2009 4:09:21 am Hans Petter Selasky wrote: > On Tuesday 08 September 2009 15:36:37 John Baldwin wrote: > > On Friday 04 September 2009 6:46:03 pm Attilio Rao wrote: > > > We all agreed the one-state was the better option but it can't be done > > > in this way because of the device_is_attached() used in the detach > > > virtual functions. Using just one transition state will break > > > device_is_attached() in those parts. > > > The right fix, as pointed out in other e-mails, is to not use > > > device_is_attached() in detach virtual functions. The better fix, in > > > my idea would involve: > > > - replace the device_is_attached() usage in detach virtual functions, > > > with a more functional support > > > - use one-state transition > > > > > > But that is just too much job to push in before then 8.0-REL and if > > > that would mean to not commit a patch and make impossible a future > > > MFC, I prefer to go with a lesser-perfect-but-still-working-approach. > > > > Wait, all you need to MFC is the change to the enum. Fixing the various > > detach routines does _not_ have to be in 8.0. That could be merged after > > the release. > > Hi, > > http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_bus.c?r1=196529&r2=196779 > > I'm sorry to say that the latest patches to subr_bus.c have broken USB. I've > got several reports on memory used after free, due to bus_generic_detach() > returning EBUSY when called from uhub_detach(). > > ... > bus_generic_detach(device_t dev) > { > device_t child; > int error; > > if (dev->state != DS_ATTACHED) > return (EBUSY); > > TAILQ_FOREACH(child, &dev->children, link) { > if ((error = device_detach(child)) != 0) > return (error); > } > > return (0); > } > > A fix for USB is available here: > > http://perforce.freebsd.org/chv.cgi?CH=168387 I think bus_generic_detach() needs to work when called from a foo_detach() routine, so I think you don't need the USB changes. Even if the new states get reintroduced bus_generic_detach() will still have to work correctly the way you had used it. -- John Baldwin From hselasky at c2i.net Mon Sep 14 14:21:59 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Sep 14 14:22:06 2009 Subject: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) In-Reply-To: <200909140852.49192.jhb@freebsd.org> References: <200909031340.n83Defkv034013@svn.freebsd.org> <200909121009.22931.hselasky@c2i.net> <200909140852.49192.jhb@freebsd.org> Message-ID: <200909141522.25635.hselasky@c2i.net> On Monday 14 September 2009 14:52:48 John Baldwin wrote: > > I think bus_generic_detach() needs to work when called from a foo_detach() > routine, so I think you don't need the USB changes. Even if the new states > get reintroduced bus_generic_detach() will still have to work correctly the > way you had used it. Ok. --HPS From bugmaster at FreeBSD.org Mon Sep 21 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 21 11:07:31 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200909211106.n8LB6odN030163@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From ed at 80386.nl Mon Sep 21 11:26:58 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Sep 21 11:27:11 2009 Subject: tmux(1) in base Message-ID: <20090921112657.GW95398@hoeg.nl> Hi all, At the DevSummit in Cambridge we briefly discussed including tmux(1) in the base system. We recently had window(1) there, but unfortunately window(1) was a very limited tool, compared to tools like screen(1) and tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first has a better license and very active maintenance. I was talking with the author on IRC the other day and it seemed like I spoke with him at a fortunate moment, because he was just about to release version 1.0. I think it would be nice to import this into HEAD, which means FreeBSD 9.0 (maybe 8.1?) will include it by default. How to test tmux in base: - Download this tarball and extract it to contrib/tmux: http://downloads.sourceforge.net/tmux/tmux-1.0.tar.gz - Apply the following patch: http://80386.nl/pub/tmux.diff Comments? -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090921/b088f4d9/attachment.pgp From ed at 80386.nl Mon Sep 21 11:35:56 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Sep 21 11:36:04 2009 Subject: tmux(1) in base In-Reply-To: <20090921112917.GA89971@freebsd.org> References: <20090921112657.GW95398@hoeg.nl> <20090921112917.GA89971@freebsd.org> Message-ID: <20090921113556.GX95398@hoeg.nl> * Roman Divacky wrote: > can tmux be configured to be 100% compatible with screen? if so > are we going to ship with such a config on default? Well, we could ship a screen-like config in /usr/share/examples, but in my opinion we shouldn't enable this by default. It only makes it more confusing when people switch to different operating systems that don't use this config. I do think tmux's use of ^B instead of ^A by default is a bit awkward... -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090921/0c483e37/attachment.pgp From rdivacky at FreeBSD.org Mon Sep 21 11:51:09 2009 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Mon Sep 21 11:51:15 2009 Subject: tmux(1) in base In-Reply-To: <20090921112657.GW95398@hoeg.nl> References: <20090921112657.GW95398@hoeg.nl> Message-ID: <20090921112917.GA89971@freebsd.org> On Mon, Sep 21, 2009 at 01:26:57PM +0200, Ed Schouten wrote: > Hi all, > > At the DevSummit in Cambridge we briefly discussed including tmux(1) in > the base system. We recently had window(1) there, but unfortunately > window(1) was a very limited tool, compared to tools like screen(1) and > tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first has a > better license and very active maintenance. > > I was talking with the author on IRC the other day and it seemed like I > spoke with him at a fortunate moment, because he was just about to > release version 1.0. I think it would be nice to import this into HEAD, > which means FreeBSD 9.0 (maybe 8.1?) will include it by default. > > How to test tmux in base: > > - Download this tarball and extract it to contrib/tmux: > http://downloads.sourceforge.net/tmux/tmux-1.0.tar.gz > - Apply the following patch: > http://80386.nl/pub/tmux.diff > > Comments? can tmux be configured to be 100% compatible with screen? if so are we going to ship with such a config on default? From wollman at hergotha.csail.mit.edu Mon Sep 21 12:37:53 2009 From: wollman at hergotha.csail.mit.edu (Garrett Wollman) Date: Mon Sep 21 12:38:00 2009 Subject: tmux(1) in base In-Reply-To: <20090921112657.GW95398@hoeg.nl> Message-ID: <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> In article <20090921112657.GW95398@hoeg.nl>, Ed Schouten writes: >At the DevSummit in Cambridge we briefly discussed including tmux(1) in >the base system. We recently had window(1) there, but unfortunately >window(1) was a very limited tool, compared to tools like screen(1) and >tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first has a >better license and very active maintenance. Can you explain why any such utility needs to be in the base system? I'm not seeing it. We have enough things in the base that most users will never use as it is. -GAWollman From alfred at freebsd.org Mon Sep 21 13:03:46 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Mon Sep 21 13:03:52 2009 Subject: tmux(1) in base In-Reply-To: <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> References: <20090921112657.GW95398@hoeg.nl> <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> Message-ID: <20090921130346.GY21946@elvis.mu.org> * Garrett Wollman [090921 05:39] wrote: > In article <20090921112657.GW95398@hoeg.nl>, Ed Schouten writes: > > >At the DevSummit in Cambridge we briefly discussed including tmux(1) in > >the base system. We recently had window(1) there, but unfortunately > >window(1) was a very limited tool, compared to tools like screen(1) and > >tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first has a > >better license and very active maintenance. > > Can you explain why any such utility needs to be in the base system? > I'm not seeing it. We have enough things in the base that most users > will never use as it is. I think he already explained that it's supposedly much better than window(1) with a kinder license than screen(1). We really ought to ship with a screen(1)-like program. hopefully we can make it screen compat rather than having something people are not familiar with in base. Any chance in getting the author to go to ^A and be more "Screenish" so people don't have to learn a new tool? Honestly, if it's very different, the people will just continue to install/use screen. -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From wollman at hergotha.csail.mit.edu Mon Sep 21 13:09:41 2009 From: wollman at hergotha.csail.mit.edu (Garrett Wollman) Date: Mon Sep 21 13:09:47 2009 Subject: tmux(1) in base In-Reply-To: <20090921130346.GY21946@elvis.mu.org> References: <20090921112657.GW95398@hoeg.nl> <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> Message-ID: <200909211309.n8LD9eTr017654@hergotha.csail.mit.edu> In article <20090921130346.GY21946@elvis.mu.org> you write: >I think he already explained that it's supposedly much better than >window(1) with a kinder license than screen(1). > >We really ought to ship with a screen(1)-like program. sudo pkg_add -r screen Problem solved. -GAWollman From cokane at FreeBSD.org Mon Sep 21 13:15:02 2009 From: cokane at FreeBSD.org (Coleman Kane) Date: Mon Sep 21 13:15:08 2009 Subject: tmux(1) in base In-Reply-To: <20090921113556.GX95398@hoeg.nl> References: <20090921112657.GW95398@hoeg.nl> <20090921112917.GA89971@freebsd.org> <20090921113556.GX95398@hoeg.nl> Message-ID: <1253537983.1757.5.camel@localhost> On Mon, 2009-09-21 at 13:35 +0200, Ed Schouten wrote: > * Roman Divacky wrote: > > can tmux be configured to be 100% compatible with screen? if so > > are we going to ship with such a config on default? > > Well, we could ship a screen-like config in /usr/share/examples, but in > my opinion we shouldn't enable this by default. It only makes it more > confusing when people switch to different operating systems that don't > use this config. I do think tmux's use of ^B instead of ^A by default is > a bit awkward... > Funny. I always considered (and still consider, but live with it) screen's use of ^A to be quite awkward and annoying, myself, since it conflicts with using ^A for jump-to-start-of-line. -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090921/266e03d3/attachment.pgp From pieter at degoeje.nl Mon Sep 21 13:28:55 2009 From: pieter at degoeje.nl (Pieter de Goeje) Date: Mon Sep 21 13:29:01 2009 Subject: tmux(1) in base In-Reply-To: <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> References: <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> Message-ID: <200909211516.48748.pieter@degoeje.nl> On Monday 21 September 2009 14:37:46 Garrett Wollman wrote: > In article <20090921112657.GW95398@hoeg.nl>, Ed Schouten writes: > > >At the DevSummit in Cambridge we briefly discussed including tmux(1) in > >the base system. We recently had window(1) there, but unfortunately > >window(1) was a very limited tool, compared to tools like screen(1) and > >tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first has a > >better license and very active maintenance. > > Can you explain why any such utility needs to be in the base system? > I'm not seeing it. We have enough things in the base that most users > will never use as it is. > > -GAWollman I would very much like to see this in the base system, as screen is currently the first port I install on all systems I manage. Anything that takes more than one minute I run in screen, such as buildworld/kernel, installation of certain ports etc. If tmux was in the basesystem, I wouldn't have to extract or mount the ports directory before updating the system to the desired version of FreeBSD. Screen/tmux is especially important when such tasks are run remotely through SSH. It could also be useful in single user mode when all you have is one console. It would be even better if there was a hardlink from screen to tmux. It could then detect it was started as screen and use screen compatible mode ;-) -- Pieter de Goeje From joel at FreeBSD.org Mon Sep 21 15:10:20 2009 From: joel at FreeBSD.org (Joel Dahl) Date: Mon Sep 21 15:10:32 2009 Subject: tmux(1) in base In-Reply-To: <20090921112657.GW95398@hoeg.nl> References: <20090921112657.GW95398@hoeg.nl> Message-ID: <4AB792B7.10206@FreeBSD.org> Ed Schouten skrev: > Hi all, > > At the DevSummit in Cambridge we briefly discussed including tmux(1) in > the base system. We recently had window(1) there, but unfortunately > window(1) was a very limited tool, compared to tools like screen(1) and > tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first has a > better license and very active maintenance. > > I was talking with the author on IRC the other day and it seemed like I > spoke with him at a fortunate moment, because he was just about to > release version 1.0. I think it would be nice to import this into HEAD, > which means FreeBSD 9.0 (maybe 8.1?) will include it by default. > > How to test tmux in base: > > - Download this tarball and extract it to contrib/tmux: > http://downloads.sourceforge.net/tmux/tmux-1.0.tar.gz > - Apply the following patch: > http://80386.nl/pub/tmux.diff > > Comments? Yes, please! Screen has almost always been the first thing I install on new machines, but recently I've been switching more and more machines over to tmux instead. Having it in base would be a great addition. -- Joel From sgk at troutmask.apl.washington.edu Mon Sep 21 15:46:28 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Mon Sep 21 15:47:31 2009 Subject: tmux(1) in base In-Reply-To: <20090921112657.GW95398@hoeg.nl> References: <20090921112657.GW95398@hoeg.nl> Message-ID: <20090921154621.GA24208@troutmask.apl.washington.edu> On Mon, Sep 21, 2009 at 01:26:57PM +0200, Ed Schouten wrote: > Hi all, > > At the DevSummit in Cambridge we briefly discussed including tmux(1) in > the base system. We recently had window(1) there, but unfortunately > window(1) was a very limited tool, compared to tools like screen(1) and > tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first has a > better license and very active maintenance. > > I was talking with the author on IRC the other day and it seemed like I > spoke with him at a fortunate moment, because he was just about to > release version 1.0. I think it would be nice to import this into HEAD, > which means FreeBSD 9.0 (maybe 8.1?) will include it by default. > > How to test tmux in base: > > - Download this tarball and extract it to contrib/tmux: > http://downloads.sourceforge.net/tmux/tmux-1.0.tar.gz > - Apply the following patch: > http://80386.nl/pub/tmux.diff > > Comments? > I've used FreeBSD since it was known as 386bsd+patchkit. In that time, I've used window/screen exactly zero times. IMHO, neither screen nor tmux should be in the base system. These are easily installed from the Ports Collection. -- Steve From miwi at FreeBSD.org Mon Sep 21 15:49:42 2009 From: miwi at FreeBSD.org (Martin Wilke) Date: Mon Sep 21 15:49:55 2009 Subject: tmux(1) in base In-Reply-To: <20090921112657.GW95398@hoeg.nl> References: <20090921112657.GW95398@hoeg.nl> Message-ID: <20090921153320.GQ19491@bsdcrew.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Sep 21, 2009 at 01:26:57PM +0200, Ed Schouten wrote: > Hi all, > > At the DevSummit in Cambridge we briefly discussed including tmux(1) in > the base system. We recently had window(1) there, but unfortunately > window(1) was a very limited tool, compared to tools like screen(1) and > tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first has a > better license and very active maintenance. > > I was talking with the author on IRC the other day and it seemed like I > spoke with him at a fortunate moment, because he was just about to > release version 1.0. I think it would be nice to import this into HEAD, > which means FreeBSD 9.0 (maybe 8.1?) will include it by default. > > How to test tmux in base: > > - Download this tarball and extract it to contrib/tmux: > http://downloads.sourceforge.net/tmux/tmux-1.0.tar.gz > - Apply the following patch: > http://80386.nl/pub/tmux.diff > > Comments? I?d also like to see that in src. > > -- > Ed Schouten > WWW: http://80386.nl/ - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkq3nMAACgkQdLJIhLHm/OkFAwCgsuODOu2Ge1ECFnJ6w6qdTAKu yC8AoIsYivL7O2PHv0stP9tfJWocLzEV =RXzT -----END PGP SIGNATURE----- From alfred at freebsd.org Mon Sep 21 16:09:55 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Mon Sep 21 16:10:02 2009 Subject: tmux(1) in base In-Reply-To: <200909211309.n8LD9eTr017654@hergotha.csail.mit.edu> References: <20090921112657.GW95398@hoeg.nl> <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> <200909211309.n8LD9eTr017654@hergotha.csail.mit.edu> Message-ID: <20090921160955.GZ21946@elvis.mu.org> * Garrett Wollman [090921 06:10] wrote: > In article <20090921130346.GY21946@elvis.mu.org> you write: > > >I think he already explained that it's supposedly much better than > >window(1) with a kinder license than screen(1). > > > >We really ought to ship with a screen(1)-like program. > > sudo pkg_add -r screen > > Problem solved. WORKS GREAT ESP WHEN NETWORK IS DOWN AND SOMEONE NEEDS MY HELP. WORKS AWESOME ON REALLY OLD MACHINES WHERE PACKAGES NO LONGER EXIST. Note: Apple, which cares more about a usable userland unix than we do at this time has screen installed in base as well. -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From joel at FreeBSD.org Mon Sep 21 16:17:15 2009 From: joel at FreeBSD.org (Joel Dahl) Date: Mon Sep 21 16:17:21 2009 Subject: tmux(1) in base In-Reply-To: <20090921160955.GZ21946@elvis.mu.org> References: <20090921112657.GW95398@hoeg.nl> <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> <200909211309.n8LD9eTr017654@hergotha.csail.mit.edu> <20090921160955.GZ21946@elvis.mu.org> Message-ID: <4AB7A708.5080209@FreeBSD.org> Alfred Perlstein skrev: > * Garrett Wollman [090921 06:10] wrote: >> In article <20090921130346.GY21946@elvis.mu.org> you write: >> >>> I think he already explained that it's supposedly much better than >>> window(1) with a kinder license than screen(1). >>> >>> We really ought to ship with a screen(1)-like program. >> sudo pkg_add -r screen >> >> Problem solved. > > WORKS GREAT ESP WHEN NETWORK IS DOWN AND SOMEONE NEEDS MY HELP. > > WORKS AWESOME ON REALLY OLD MACHINES WHERE PACKAGES NO LONGER > EXIST. > > Note: Apple, which cares more about a usable userland unix than > we do at this time has screen installed in base as well. OpenBSD has tmux in base...and I've seen discussions on the NetBSD lists about importing tmux (as a window(1) replacement) into NetBSD base as well... :-) -- Joel From alfred at freebsd.org Mon Sep 21 16:19:47 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Mon Sep 21 16:19:53 2009 Subject: tmux(1) in base In-Reply-To: <4AB7A708.5080209@FreeBSD.org> References: <20090921112657.GW95398@hoeg.nl> <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> <200909211309.n8LD9eTr017654@hergotha.csail.mit.edu> <20090921160955.GZ21946@elvis.mu.org> <4AB7A708.5080209@FreeBSD.org> Message-ID: <20090921161946.GA21946@elvis.mu.org> * Joel Dahl [090921 09:17] wrote: > Alfred Perlstein skrev: > >* Garrett Wollman [090921 06:10] wrote: > >>In article <20090921130346.GY21946@elvis.mu.org> you write: > >> > >>>I think he already explained that it's supposedly much better than > >>>window(1) with a kinder license than screen(1). > >>> > >>>We really ought to ship with a screen(1)-like program. > >>sudo pkg_add -r screen > >> > >>Problem solved. > > > >WORKS GREAT ESP WHEN NETWORK IS DOWN AND SOMEONE NEEDS MY HELP. > > > >WORKS AWESOME ON REALLY OLD MACHINES WHERE PACKAGES NO LONGER > >EXIST. > > > >Note: Apple, which cares more about a usable userland unix than > >we do at this time has screen installed in base as well. > > OpenBSD has tmux in base...and I've seen discussions on the NetBSD lists > about importing tmux (as a window(1) replacement) into NetBSD base as > well... :-) I dunno Joel, we wouldn't want to get crazy and ship a system that was usable out of the box, I'd like to go back to a Solaris circa 1999 like system, y'know, kernel+/bin/sh, don't need much more than that y'know... -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From sgk at troutmask.apl.washington.edu Mon Sep 21 16:30:27 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Mon Sep 21 16:30:34 2009 Subject: tmux(1) in base In-Reply-To: <20090921161946.GA21946@elvis.mu.org> References: <20090921112657.GW95398@hoeg.nl> <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> <200909211309.n8LD9eTr017654@hergotha.csail.mit.edu> <20090921160955.GZ21946@elvis.mu.org> <4AB7A708.5080209@FreeBSD.org> <20090921161946.GA21946@elvis.mu.org> Message-ID: <20090921163027.GA24651@troutmask.apl.washington.edu> On Mon, Sep 21, 2009 at 09:19:46AM -0700, Alfred Perlstein wrote: > * Joel Dahl [090921 09:17] wrote: > > Alfred Perlstein skrev: > > >* Garrett Wollman [090921 06:10] wrote: > > >>In article <20090921130346.GY21946@elvis.mu.org> you write: > > >> > > >>>I think he already explained that it's supposedly much better than > > >>>window(1) with a kinder license than screen(1). > > >>> > > >>>We really ought to ship with a screen(1)-like program. > > >>sudo pkg_add -r screen > > >> > > >>Problem solved. > > > > > >WORKS GREAT ESP WHEN NETWORK IS DOWN AND SOMEONE NEEDS MY HELP. > > > > > >WORKS AWESOME ON REALLY OLD MACHINES WHERE PACKAGES NO LONGER > > >EXIST. > > > > > >Note: Apple, which cares more about a usable userland unix than > > >we do at this time has screen installed in base as well. > > > > OpenBSD has tmux in base...and I've seen discussions on the NetBSD lists > > about importing tmux (as a window(1) replacement) into NetBSD base as > > well... :-) > > I dunno Joel, we wouldn't want to get crazy and ship a system that > was usable out of the box, I'd like to go back to a Solaris > circa 1999 like system, y'know, kernel+/bin/sh, don't need much > more than that y'know... > When you install the box, install the port. This isn't rocket science. Can we also add perl back to the base system? It is much more useful than tmux/screen. -- Steve From alfred at freebsd.org Mon Sep 21 16:34:40 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Mon Sep 21 16:34:47 2009 Subject: tmux(1) in base In-Reply-To: <20090921163027.GA24651@troutmask.apl.washington.edu> References: <20090921112657.GW95398@hoeg.nl> <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> <200909211309.n8LD9eTr017654@hergotha.csail.mit.edu> <20090921160955.GZ21946@elvis.mu.org> <4AB7A708.5080209@FreeBSD.org> <20090921161946.GA21946@elvis.mu.org> <20090921163027.GA24651@troutmask.apl.washington.edu> Message-ID: <20090921163440.GC21946@elvis.mu.org> * Steve Kargl [090921 09:30] wrote: > On Mon, Sep 21, 2009 at 09:19:46AM -0700, Alfred Perlstein wrote: > > * Joel Dahl [090921 09:17] wrote: > > > Alfred Perlstein skrev: > > > >* Garrett Wollman [090921 06:10] wrote: > > > >>In article <20090921130346.GY21946@elvis.mu.org> you write: > > > >> > > > >>>I think he already explained that it's supposedly much better than > > > >>>window(1) with a kinder license than screen(1). > > > >>> > > > >>>We really ought to ship with a screen(1)-like program. > > > >>sudo pkg_add -r screen > > > >> > > > >>Problem solved. > > > > > > > >WORKS GREAT ESP WHEN NETWORK IS DOWN AND SOMEONE NEEDS MY HELP. > > > > > > > >WORKS AWESOME ON REALLY OLD MACHINES WHERE PACKAGES NO LONGER > > > >EXIST. > > > > > > > >Note: Apple, which cares more about a usable userland unix than > > > >we do at this time has screen installed in base as well. > > > > > > OpenBSD has tmux in base...and I've seen discussions on the NetBSD lists > > > about importing tmux (as a window(1) replacement) into NetBSD base as > > > well... :-) > > > > I dunno Joel, we wouldn't want to get crazy and ship a system that > > was usable out of the box, I'd like to go back to a Solaris > > circa 1999 like system, y'know, kernel+/bin/sh, don't need much > > more than that y'know... > > > > When you install the box, install the port. This isn't rocket > science. > > Can we also add perl back to the base system? It is much more > useful than tmux/screen. 1) Perl is dead. 2) We could add something like ruby or python if someone could get the bootstrap working without build nicely. -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From sgk at troutmask.apl.washington.edu Mon Sep 21 16:50:13 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Mon Sep 21 16:50:22 2009 Subject: tmux(1) in base In-Reply-To: <20090921163440.GC21946@elvis.mu.org> References: <20090921112657.GW95398@hoeg.nl> <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> <200909211309.n8LD9eTr017654@hergotha.csail.mit.edu> <20090921160955.GZ21946@elvis.mu.org> <4AB7A708.5080209@FreeBSD.org> <20090921161946.GA21946@elvis.mu.org> <20090921163027.GA24651@troutmask.apl.washington.edu> <20090921163440.GC21946@elvis.mu.org> Message-ID: <20090921165013.GA24778@troutmask.apl.washington.edu> On Mon, Sep 21, 2009 at 09:34:40AM -0700, Alfred Perlstein wrote: > * Steve Kargl [090921 09:30] wrote: > > On Mon, Sep 21, 2009 at 09:19:46AM -0700, Alfred Perlstein wrote: > > > > > > I dunno Joel, we wouldn't want to get crazy and ship a system that > > > was usable out of the box, I'd like to go back to a Solaris > > > circa 1999 like system, y'know, kernel+/bin/sh, don't need much > > > more than that y'know... > > > > > > > When you install the box, install the port. This isn't rocket > > science. > > > > Can we also add perl back to the base system? It is much more > > useful than tmux/screen. > > 1) Perl is dead. > 2) We could add something like ruby or python if someone could > get the bootstrap working without build nicely. > It was a rhetorical question, Alfred. BTW, Perl is far from dead. It appears none of the customers you support use SpamAssassin, apache, teTeX, jdk16, gtk, or any number of other ports that list perl as a dependence. troutmask:kargl[206] pkg_info -R perl-5.8.9_3 | grep -v p5- | wc -l 63 troutmask:kargl[208] pkg_info -R perl-5.8.9_3 | wc -l 97 -- Steve From kabaev at gmail.com Mon Sep 21 17:12:23 2009 From: kabaev at gmail.com (Alexander Kabaev) Date: Mon Sep 21 17:12:28 2009 Subject: tmux(1) in base In-Reply-To: <20090921113556.GX95398@hoeg.nl> References: <20090921112657.GW95398@hoeg.nl> <20090921112917.GA89971@freebsd.org> <20090921113556.GX95398@hoeg.nl> Message-ID: <20090921131214.1d06b1da@kan.dnsalias.net> On Mon, 21 Sep 2009 13:35:56 +0200 Ed Schouten wrote: > * Roman Divacky wrote: > > can tmux be configured to be 100% compatible with screen? if so > > are we going to ship with such a config on default? > > Well, we could ship a screen-like config in /usr/share/examples, but > in my opinion we shouldn't enable this by default. It only makes it > more confusing when people switch to different operating systems that > don't use this config. I do think tmux's use of ^B instead of ^A by > default is a bit awkward... > We have many, many useful programs in ports. Please let tmux be one of them. I use screen on every system I can access too and having it in ports was never too much of a nuisance. My $0.02. -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090921/194a5058/signature.pgp From julian at elischer.org Mon Sep 21 17:15:51 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Sep 21 17:15:58 2009 Subject: tmux(1) in base In-Reply-To: <20090921154621.GA24208@troutmask.apl.washington.edu> References: <20090921112657.GW95398@hoeg.nl> <20090921154621.GA24208@troutmask.apl.washington.edu> Message-ID: <4AB7B230.1040101@elischer.org> Steve Kargl wrote: > On Mon, Sep 21, 2009 at 01:26:57PM +0200, Ed Schouten wrote: >> Hi all, >> >> At the DevSummit in Cambridge we briefly discussed including tmux(1) in >> the base system. We recently had window(1) there, but unfortunately >> window(1) was a very limited tool, compared to tools like screen(1) and >> tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first has a >> better license and very active maintenance. >> >> I was talking with the author on IRC the other day and it seemed >> like I spoke with him at a fortunate moment, because he was just >> about to release version 1.0. I think it would be nice to import >> this into HEAD, which means FreeBSD 9.0 (maybe 8.1?) will include >> it by default. >> >> How to test tmux in base: >> >> - Download this tarball and extract it to contrib/tmux: >> http://downloads.sourceforge.net/tmux/tmux-1.0.tar.gz >> - Apply the following patch: >> http://80386.nl/pub/tmux.diff >> >> Comments? >> > > I've used FreeBSD since it was known as 386bsd+patchkit. In that > time, I've used window/screen exactly zero times. IMHO, neither > screen nor tmux should be in the base system. These are easily > installed from the Ports Collection. I always use screen. I used to use window sometimes but screen was better. While it'd be noce to have it in the base system, it's always been ok for me to have it as a port and it probably can continue to be there. I'm not sure that putting tmux in the base system is worth while. It's being activly developed which means that we'll always be out of date. for Alfred's support point.. to watch soemoe else for support reasons I use watch -w Julian From oberman at es.net Mon Sep 21 17:39:57 2009 From: oberman at es.net (Kevin Oberman) Date: Mon Sep 21 17:40:04 2009 Subject: tmux(1) in base In-Reply-To: Your message of "Mon, 21 Sep 2009 13:26:57 +0200." <20090921112657.GW95398@hoeg.nl> Message-ID: <20090921173936.65F881CC37@ptavv.es.net> > Date: Mon, 21 Sep 2009 13:26:57 +0200 > From: Ed Schouten > Sender: owner-freebsd-current@freebsd.org > > Hi all, > > At the DevSummit in Cambridge we briefly discussed including tmux(1) in > the base system. We recently had window(1) there, but unfortunately > window(1) was a very limited tool, compared to tools like screen(1) and > tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first has a > better license and very active maintenance. > > I was talking with the author on IRC the other day and it seemed like I > spoke with him at a fortunate moment, because he was just about to > release version 1.0. I think it would be nice to import this into HEAD, > which means FreeBSD 9.0 (maybe 8.1?) will include it by default. > > How to test tmux in base: > > - Download this tarball and extract it to contrib/tmux: > http://downloads.sourceforge.net/tmux/tmux-1.0.tar.gz > - Apply the following patch: > http://80386.nl/pub/tmux.diff > > Comments? While I make fairly heavy use of screen(1), I am unclear on why this functionality should be included in the base. I can (and do) install it on most systems I build, but I can't see any systemic justification for putting it in the base system. It just makes updating tmux harder. Remember the fun of dealing with Perl when it was in the base system? (Yes, Perl was probably about the worst possible case.) Unless a tool is maintained by the FreeBSD project or is so essential that most it would be inadvisable to have a base system where it was not available (ntp, SSL libraries, C compiler, ssh, ...), I really think adding things to the base is best avoided. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From keramida at freebsd.org Mon Sep 21 17:47:28 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Mon Sep 21 17:47:41 2009 Subject: tmux(1) in base In-Reply-To: <20090921113556.GX95398@hoeg.nl> (Ed Schouten's message of "Mon, 21 Sep 2009 13:35:56 +0200") References: <20090921112657.GW95398@hoeg.nl> <20090921112917.GA89971@freebsd.org> <20090921113556.GX95398@hoeg.nl> Message-ID: <87ocp443e2.fsf@kobe.laptop> On Mon, 21 Sep 2009 13:35:56 +0200, Ed Schouten wrote: > * Roman Divacky wrote: >> can tmux be configured to be 100% compatible with screen? if so >> are we going to ship with such a config on default? > > Well, we could ship a screen-like config in /usr/share/examples, but in > my opinion we shouldn't enable this by default. It only makes it more > confusing when people switch to different operating systems that don't > use this config. I do think tmux's use of ^B instead of ^A by default is > a bit awkward... ^A is rather comfortable with my Caps Lock key swapped with Ctrl. If the escape character of tmux can be configured to be ^A in the personal startup configuration of each user, the awkwardness of ^B is really a very minor issue. IMO, a sample screen-like config in /usr/share/examples will go a long way towards making tmux in the base system a comfortable and viable screen alternative :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090921/03fc1030/attachment.pgp From lulf at pvv.ntnu.no Mon Sep 21 18:21:54 2009 From: lulf at pvv.ntnu.no (Ulf Lilleengen) Date: Mon Sep 21 18:22:27 2009 Subject: tmux(1) in base In-Reply-To: <20090921131214.1d06b1da@kan.dnsalias.net> References: <20090921112657.GW95398@hoeg.nl> <20090921112917.GA89971@freebsd.org> <20090921113556.GX95398@hoeg.nl> <20090921131214.1d06b1da@kan.dnsalias.net> Message-ID: <4AB7C42F.50704@pvv.ntnu.no> Alexander Kabaev wrote: > On Mon, 21 Sep 2009 13:35:56 +0200 > Ed Schouten wrote: > >> * Roman Divacky wrote: >>> can tmux be configured to be 100% compatible with screen? if so >>> are we going to ship with such a config on default? >> Well, we could ship a screen-like config in /usr/share/examples, but >> in my opinion we shouldn't enable this by default. It only makes it >> more confusing when people switch to different operating systems that >> don't use this config. I do think tmux's use of ^B instead of ^A by >> default is a bit awkward... >> > > We have many, many useful programs in ports. Please let tmux be one of > them. I use screen on every system I can access too and having it in > ports was never too much of a nuisance. > > My $0.02. > +1 From 000.fbsd at quip.cz Mon Sep 21 18:37:40 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Mon Sep 21 18:37:46 2009 Subject: tmux(1) in base In-Reply-To: <20090921173936.65F881CC37@ptavv.es.net> References: <20090921173936.65F881CC37@ptavv.es.net> Message-ID: <4AB7C396.5050802@quip.cz> Kevin Oberman wrote: >>Date: Mon, 21 Sep 2009 13:26:57 +0200 >>From: Ed Schouten >>Sender: owner-freebsd-current@freebsd.org >> >>Hi all, >> >>At the DevSummit in Cambridge we briefly discussed including tmux(1) in >>the base system. We recently had window(1) there, but unfortunately >>window(1) was a very limited tool, compared to tools like screen(1) and >>tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first has a >>better license and very active maintenance. >> >>I was talking with the author on IRC the other day and it seemed like I >>spoke with him at a fortunate moment, because he was just about to >>release version 1.0. I think it would be nice to import this into HEAD, >>which means FreeBSD 9.0 (maybe 8.1?) will include it by default. >> >>How to test tmux in base: >> >>- Download this tarball and extract it to contrib/tmux: >> http://downloads.sourceforge.net/tmux/tmux-1.0.tar.gz >>- Apply the following patch: >> http://80386.nl/pub/tmux.diff >> >>Comments? > > > While I make fairly heavy use of screen(1), I am unclear on why this > functionality should be included in the base. I can (and do) install it > on most systems I build, but I can't see any systemic justification for > putting it in the base system. It just makes updating tmux > harder. Remember the fun of dealing with Perl when it was in the base > system? (Yes, Perl was probably about the worst possible case.) > > Unless a tool is maintained by the FreeBSD project or is so essential > that most it would be inadvisable to have a base system where it was > not available (ntp, SSL libraries, C compiler, ssh, ...), I really think > adding things to the base is best avoided. +1 from me. I am daily screen(1) user but I think it (tmux or screen) should stay as port. It is better to have minimalistic base and easily upgradable ports. Miroslav Lachman From cokane at FreeBSD.org Mon Sep 21 19:05:45 2009 From: cokane at FreeBSD.org (Coleman Kane) Date: Mon Sep 21 19:05:52 2009 Subject: tmux(1) in base In-Reply-To: <4AB7C396.5050802@quip.cz> References: <20090921173936.65F881CC37@ptavv.es.net> <4AB7C396.5050802@quip.cz> Message-ID: <1253559924.2236.6.camel@localhost> On Mon, 2009-09-21 at 20:19 +0200, Miroslav Lachman wrote: > Kevin Oberman wrote: > >>Date: Mon, 21 Sep 2009 13:26:57 +0200 > >>From: Ed Schouten > >>Sender: owner-freebsd-current@freebsd.org > >> > >>Hi all, > >> > >>At the DevSummit in Cambridge we briefly discussed including tmux(1) in > >>the base system. We recently had window(1) there, but unfortunately > >>window(1) was a very limited tool, compared to tools like screen(1) and > >>tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first has a > >>better license and very active maintenance. > >> > >>I was talking with the author on IRC the other day and it seemed like I > >>spoke with him at a fortunate moment, because he was just about to > >>release version 1.0. I think it would be nice to import this into HEAD, > >>which means FreeBSD 9.0 (maybe 8.1?) will include it by default. > >> > >>How to test tmux in base: > >> > >>- Download this tarball and extract it to contrib/tmux: > >> http://downloads.sourceforge.net/tmux/tmux-1.0.tar.gz > >>- Apply the following patch: > >> http://80386.nl/pub/tmux.diff > >> > >>Comments? > > > > > > While I make fairly heavy use of screen(1), I am unclear on why this > > functionality should be included in the base. I can (and do) install it > > on most systems I build, but I can't see any systemic justification for > > putting it in the base system. It just makes updating tmux > > harder. Remember the fun of dealing with Perl when it was in the base > > system? (Yes, Perl was probably about the worst possible case.) > > > > Unless a tool is maintained by the FreeBSD project or is so essential > > that most it would be inadvisable to have a base system where it was > > not available (ntp, SSL libraries, C compiler, ssh, ...), I really think > > adding things to the base is best avoided. > > +1 from me. > > I am daily screen(1) user but I think it (tmux or screen) should stay as > port. It is better to have minimalistic base and easily upgradable ports. > > Miroslav Lachman I agree with this. I would prefer it if more stuff would get relegated to ports (such as sendmail), and I am not really interested in seeing the base system expanded with yet another tool. If I really needed screen or tmux on a system that I was installing from disk, I would make sure to have it written to a packages ISO with all the other third-party applications that I need. I also feel that ports is a more visible place for such a tool to live if ever in the future the community needs someone to take over its maintenance. -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090921/bf7736a4/attachment.pgp From kmacy at freebsd.org Mon Sep 21 19:52:36 2009 From: kmacy at freebsd.org (K. Macy) Date: Mon Sep 21 19:52:43 2009 Subject: tmux(1) in base In-Reply-To: <4AB792B7.10206@FreeBSD.org> References: <20090921112657.GW95398@hoeg.nl> <4AB792B7.10206@FreeBSD.org> Message-ID: <82c4140e0909211225j5ab8ecf3q2645323bec99274d@mail.gmail.com> > Screen has almost always been the first thing I install on new machines, but > recently I've been switching more and more machines over to tmux instead. > Having it in base would be a great addition. > The first thing *I* always install is xemacs and zsh... From oberman at es.net Mon Sep 21 21:02:08 2009 From: oberman at es.net (Kevin Oberman) Date: Mon Sep 21 21:02:15 2009 Subject: tmux(1) in base In-Reply-To: Your message of "Mon, 21 Sep 2009 12:25:13 PDT." <82c4140e0909211225j5ab8ecf3q2645323bec99274d@mail.gmail.com> Message-ID: <20090921210159.2D4D51CC37@ptavv.es.net> > Date: Mon, 21 Sep 2009 12:25:13 -0700 > From: "K. Macy" > Sender: owner-freebsd-current@freebsd.org > > > Screen has almost always been the first thing I install on new > > machines, but recently I've been switching more and more machines > > over to tmux instead. Having it in base would be a great addition. > > > > The first thing *I* always install is xemacs and zsh... most(1) and xemacs(1), but this is getting seriously off topic. 1. Should such a tool be in the base system? 2. If so, should it be screen(1) or tmux(1) I vote 'no' to 1 and 'tmux(1)' for 2. I've just spent a fews minutes with tmux and it has several wins over screen. Then again, FreeBSD is not a democracy, so 'voting' is really just advisory. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From phk at phk.freebsd.dk Mon Sep 21 21:06:54 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon Sep 21 21:07:01 2009 Subject: tmux(1) in base In-Reply-To: Your message of "Mon, 21 Sep 2009 09:34:40 MST." <20090921163440.GC21946@elvis.mu.org> Message-ID: <2133.1253566188@critter.freebsd.dk> Gentlemen, This is an official announcement: The EuroBSDcon2009 Conference is *over*. This bikeshed was started too late to have any chance to qualify as a "conference-bikeshed". If you continue this bikeshed, which is clearly outside a approved venue (as defined in the projects Rules for Bikesheds, section 7.a.1.K, second paragraph) you will be issued penalty, between closing 10 PR's properly and up to a "10 sequential polite, helpful and gramatically correct emails" handicap, in the next official and properly approved project bikeshed. Thank you. On behalf of The Governing Board for Official FreeBSD Bikeshed /s -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From des at des.no Mon Sep 21 21:31:14 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Sep 21 21:31:21 2009 Subject: tmux(1) in base In-Reply-To: <200909211309.n8LD9eTr017654@hergotha.csail.mit.edu> (Garrett Wollman's message of "Mon, 21 Sep 2009 09:09:40 -0400 (EDT)") References: <20090921112657.GW95398@hoeg.nl> <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> <200909211309.n8LD9eTr017654@hergotha.csail.mit.edu> Message-ID: <863a6gm1cv.fsf@ds4.des.no> Garrett Wollman writes: > sudo pkg_add -r screen > > Problem solved. Last I checked, there was no binary package for screen. DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Mon Sep 21 21:36:58 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Sep 21 21:37:04 2009 Subject: tmux(1) in base In-Reply-To: <20090921210159.2D4D51CC37@ptavv.es.net> (Kevin Oberman's message of "Mon, 21 Sep 2009 14:01:59 -0700") References: <20090921210159.2D4D51CC37@ptavv.es.net> Message-ID: <86y6o8kmiv.fsf@ds4.des.no> "Kevin Oberman" writes: > 1. Should such a tool be in the base system? We already have window(1). It has a number of features that screen(1) and tmux(1) lack, but it can't detach. > 2. If so, should it be screen(1) or tmux(1) The former is GPL, the latter is BSD. DES -- Dag-Erling Sm?rgrav - des@des.no From dougb at FreeBSD.org Mon Sep 21 21:44:34 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Sep 21 21:44:40 2009 Subject: tmux(1) in base In-Reply-To: <20090921112657.GW95398@hoeg.nl> References: <20090921112657.GW95398@hoeg.nl> Message-ID: <4AB7ED76.5010406@FreeBSD.org> I hate to sound negative, but I really don't find arguments of the sort, "the first thing I install on a new system is 'foo', so 'foo' should be part of the base" compelling.[1] I, like a lot of other FreeBSD users have never used screen or tmux, and probably never will. For my money nohup works just fine for long-lived processes that need a log. But even the "I don't use it so it shouldn't be there" argument is not particularly persuasive. We need to take a hard look at what kind of system we want to have. It's a lot easier to keep userland utilities like tmux up to date from the ports tree than it is in the base. That alone should be the deciding factor, but if you want to hear a chorus of the "bloat" argument then fill it in here. Rather than going down the road of putting everything that some subset of our developer base thinks makes a system "usable" into the base I would like to suggest that the effort be spent on improving the installation tools such that making a system "usable" out of the box is a matter of ticking off a few boxes at install time. That change will benefit a whole lot more users than installing one more userland tool into the base. Doug [1] If we're going to go that route then I'm installing bash. -- This .signature sanitized for your protection From des at des.no Mon Sep 21 21:55:06 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Sep 21 21:55:28 2009 Subject: tmux(1) in base In-Reply-To: <86y6o8kmiv.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Mon, 21 Sep 2009 23:36:56 +0200") References: <20090921210159.2D4D51CC37@ptavv.es.net> <86y6o8kmiv.fsf@ds4.des.no> Message-ID: <86tyywklon.fsf@ds4.des.no> Dag-Erling Sm?rgrav writes: > "Kevin Oberman" writes: > > 1. Should such a tool be in the base system? > We already have window(1). It has a number of features that screen(1) > and tmux(1) lack, but it can't detach. > > 2. If so, should it be screen(1) or tmux(1) > The former is GPL, the latter is BSD. Don't construe this as a vote in favor of importing tmux, though. I use screen pretty much everywhere, and I'm perfectly OK with installing it from ports; it's just One Of Those Things that I always do on a new machine, like installing zsh and copying over my zsh{env,rc}. DES -- Dag-Erling Sm?rgrav - des@des.no From wxs at FreeBSD.org Mon Sep 21 23:33:20 2009 From: wxs at FreeBSD.org (Wesley Shields) Date: Mon Sep 21 23:33:26 2009 Subject: tmux(1) in base In-Reply-To: <863a6gm1cv.fsf@ds4.des.no> References: <20090921112657.GW95398@hoeg.nl> <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> <200909211309.n8LD9eTr017654@hergotha.csail.mit.edu> <863a6gm1cv.fsf@ds4.des.no> Message-ID: <20090921231422.GA80793@atarininja.org> On Mon, Sep 21, 2009 at 11:31:12PM +0200, Dag-Erling Sm??rgrav wrote: > Garrett Wollman writes: > > sudo pkg_add -r screen > > > > Problem solved. > > Last I checked, there was no binary package for screen. That has recently been changed so there will be packages in the future. -- WXS From areilly at bigpond.net.au Mon Sep 21 23:46:56 2009 From: areilly at bigpond.net.au (Andrew Reilly) Date: Mon Sep 21 23:47:06 2009 Subject: tmux(1) in base In-Reply-To: <20090921160955.GZ21946@elvis.mu.org> References: <20090921112657.GW95398@hoeg.nl> <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> <200909211309.n8LD9eTr017654@hergotha.csail.mit.edu> <20090921160955.GZ21946@elvis.mu.org> Message-ID: <20090921215843.GA80840@duncan.reilly.home> On Mon, Sep 21, 2009 at 09:09:55AM -0700, Alfred Perlstein wrote: > * Garrett Wollman [090921 06:10] wrote: > > In article <20090921130346.GY21946@elvis.mu.org> you write: > > > > >I think he already explained that it's supposedly much better than > > >window(1) with a kinder license than screen(1). > > > > > >We really ought to ship with a screen(1)-like program. > > > > sudo pkg_add -r screen > > > > Problem solved. > > WORKS GREAT ESP WHEN NETWORK IS DOWN AND SOMEONE NEEDS MY HELP. Well I don't imagine that either screen or tmux are much use when the network is down. > WORKS AWESOME ON REALLY OLD MACHINES WHERE PACKAGES NO LONGER > EXIST. Adding anything to base *now* isn't going to help those machines, either. It'll just ensure that it isn't available in ports, where it *might* be useful. > Note: Apple, which cares more about a usable userland unix than > we do at this time has screen installed in base as well. Yeah, but they also include python, ruby and a full GUI e-mail client, so that's not really much of a comparison. Well, NetBSD ships with X and a bunch of extra things too, so there's clearly room for disagreement on where to draw the line. Personally, if the network is working well enough to ssh into a box, then it's probably working well enough to pkg_add whatever you need. It's not as though screen or tmux are in the same league as ssh (or even telnet) when it comes to shipping a system that is "useful" out of the box. Just IMO. FWIW. Cheers, -- Andrew From gnemmi at gmail.com Tue Sep 22 00:51:13 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Sep 22 00:51:19 2009 Subject: tmux(1) in base In-Reply-To: <4AB7ED76.5010406@FreeBSD.org> References: <20090921112657.GW95398@hoeg.nl> <4AB7ED76.5010406@FreeBSD.org> Message-ID: <19e9a5dc0909211728m159c1b50id00dec2b3f8110b0@mail.gmail.com> On Mon, Sep 21, 2009 at 6:17 PM, Doug Barton wrote: > I hate to sound negative, but I really don't find arguments of the > sort, "the first thing I install on a new system is 'foo', so 'foo' > should be part of the base" compelling.[1] I, like a lot of other > FreeBSD users have never used screen or tmux, and probably never will. > For my money nohup works just fine for long-lived processes that need > a log. But even the "I don't use it so it shouldn't be there" argument > is not particularly persuasive. > > We need to take a hard look at what kind of system we want to have. > It's a lot easier to keep userland utilities like tmux up to date from > the ports tree than it is in the base. That alone should be the > deciding factor, but if you want to hear a chorus of the "bloat" > argument then fill it in here. > > Rather than going down the road of putting everything that some subset > of our developer base thinks makes a system "usable" into the base I > would like to suggest that the effort be spent on improving the > installation tools such that making a system "usable" out of the box > is a matter of ticking off a few boxes at install time. That change > will benefit a whole lot more users than installing one more userland > tool into the base. > > Doug > +10 ... bge won't resresume from suspend, a simple kldload atapicam causes a fatal trap12 and ACPI support is just a matter of luck ... and we are at -RC1 ... > [1] If we're going to go that route then I'm installing bash. > I'd get rid of Sendmail and replace it with something more sensible like DMA (DragonFly Mail Agent) ... Even the Fedora guys are thinking about it ... regards Gonzalo Nemmi From mexas at bristol.ac.uk Tue Sep 22 08:42:14 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Sep 22 08:42:21 2009 Subject: tmux(1) in base In-Reply-To: <4AB7ED76.5010406@FreeBSD.org> References: <20090921112657.GW95398@hoeg.nl> <4AB7ED76.5010406@FreeBSD.org> Message-ID: <20090922082344.GA64877@mech-cluster241.men.bris.ac.uk> On Mon, Sep 21, 2009 at 02:17:42PM -0700, Doug Barton wrote: > I hate to sound negative, but I really don't find arguments of the > sort, "the first thing I install on a new system is 'foo', so 'foo' > should be part of the base" compelling.[1] I, like a lot of other > FreeBSD users have never used screen or tmux, and probably never will. > For my money nohup works just fine for long-lived processes that need > a log. But even the "I don't use it so it shouldn't be there" argument > is not particularly persuasive. > > We need to take a hard look at what kind of system we want to have. > It's a lot easier to keep userland utilities like tmux up to date from > the ports tree than it is in the base. That alone should be the > deciding factor, but if you want to hear a chorus of the "bloat" > argument then fill it in here. > > Rather than going down the road of putting everything that some subset > of our developer base thinks makes a system "usable" into the base I > would like to suggest that the effort be spent on improving the > installation tools such that making a system "usable" out of the box > is a matter of ticking off a few boxes at install time. That change > will benefit a whole lot more users than installing one more userland > tool into the base. I completely agree -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From boogie at lazybytes.org Tue Sep 22 10:09:58 2009 From: boogie at lazybytes.org (Sergey Vinogradov) Date: Tue Sep 22 10:10:05 2009 Subject: tmux(1) in base In-Reply-To: <20090921112657.GW95398@hoeg.nl> References: <20090921112657.GW95398@hoeg.nl> Message-ID: <20090922135435.36a3d40e@lazybytes.org> ? Mon, 21 Sep 2009 13:26:57 +0200 Ed Schouten ?????: > Hi all, > > At the DevSummit in Cambridge we briefly discussed including tmux(1) > in the base system. We recently had window(1) there, but unfortunately > window(1) was a very limited tool, compared to tools like screen(1) > and tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first > has a better license and very active maintenance. > > I was talking with the author on IRC the other day and it seemed like > I spoke with him at a fortunate moment, because he was just about to > release version 1.0. I think it would be nice to import this into > HEAD, which means FreeBSD 9.0 (maybe 8.1?) will include it by default. > > How to test tmux in base: > > - Download this tarball and extract it to contrib/tmux: > http://downloads.sourceforge.net/tmux/tmux-1.0.tar.gz > - Apply the following patch: > http://80386.nl/pub/tmux.diff > > Comments? > I don't think tmux(1) should be included in the base system. As it was mentioned, it will be hard to update it, many people will still install screen(1) because they still like it more, or just got used to it, the system will become a little more bloated, and nobody likes when that happens :) Offtopic part (maybe we should start another discussion thread): The thing I'll be happy to see someday in base system is zsh(1). tcsh(1) syntax is not Bourne shell compatible, and sh(1) sucks at interactive work; it's a big deal for me, I'd like to have a shell that can do both things simultaneously :) Despite the zsh(1) has appropriate license, it needs autotools and iconv (both GPL AFAIK), so it's hard to include in the base system. The things in the base system I always wondered about are sendmail and bind9. These are pretty heavy, and definitely are not used in every single installation. Maybe someday I'll see sendmail and bind9 in ports instead of base system. And yes, I know about WITHOUT_BIND= and WITHOUT_SENDMAIL= :) -- wbr, Boo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090922/9027ed3c/signature.pgp From nick at van-laarhoven.org Tue Sep 22 11:25:49 2009 From: nick at van-laarhoven.org (Nick Hibma) Date: Tue Sep 22 11:25:56 2009 Subject: tmux(1) in base In-Reply-To: <20090922082344.GA64877@mech-cluster241.men.bris.ac.uk> References: <20090921112657.GW95398@hoeg.nl> <4AB7ED76.5010406@FreeBSD.org> <20090922082344.GA64877@mech-cluster241.men.bris.ac.uk> Message-ID: <37B47737-E4A4-4CF3-9DAA-B0F0A4CC8901@van-laarhoven.org> >> Rather than going down the road of putting everything that some >> subset >> of our developer base thinks makes a system "usable" into the base I >> would like to suggest that the effort be spent on improving the >> installation tools such that making a system "usable" out of the box >> is a matter of ticking off a few boxes at install time. That change >> will benefit a whole lot more users than installing one more user >> land >> tool into the base. > > I completely agree While pondering a +1 for tmux in the base system, I realised that the first thing I install is bash and vim, but the existing tools are suitable for booting a system. Another argument against including it is compilation time: It takes more than 10 seconds to compile tmux (I expected it to be 1 source file to be compiled, silly me) on my Hamster-powered (tm) server, so it would add a significant of overhead to buildworld. Our package system is a tremendous asset, and wholeheartedly agree with Doug on this. So my vote is now a -1. Not that anyone cares. Nick P.S.: I've added 'tmux' to the default packages of our nanobsd image build system. Thanks for the suggestion! From 000.fbsd at quip.cz Tue Sep 22 11:36:53 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Tue Sep 22 11:37:07 2009 Subject: tmux(1) in base In-Reply-To: <20090922135435.36a3d40e@lazybytes.org> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> Message-ID: <4AB8B6D0.2000809@quip.cz> Sergey Vinogradov wrote: > ? Mon, 21 Sep 2009 13:26:57 +0200 > Ed Schouten ?????: [...] > I don't think tmux(1) should be included in the base system. As it was > mentioned, it will be hard to update it, many people will still install > screen(1) because they still like it more, or just got used to it, the > system will become a little more bloated, and nobody likes when that > happens :) [...] > The things in the base system I always wondered about are sendmail > and bind9. These are pretty heavy, and definitely are not used in every > single installation. Maybe someday I'll see sendmail and bind9 in ports > instead of base system. And yes, I know about WITHOUT_BIND= and > WITHOUT_SENDMAIL= :) I can second this. I am using Sendmail only on one machine (replaced with Postfix on the others) and the same with BIND. It should be better to not have them in base, but have them as ports with special care of FreeBSD team. It will give us better possibility of updates and fixes for users who are using them. And if SW like this will be available for install by sysinstall in some extra category as 'always on the first / minimal media' (or installed by default?), then anybody can install it if needed. Miroslav Lachman From swell.k at gmail.com Tue Sep 22 13:37:22 2009 From: swell.k at gmail.com (Anonymous) Date: Tue Sep 22 13:37:28 2009 Subject: tmux(1) in base In-Reply-To: <20090921112657.GW95398@hoeg.nl> (Ed Schouten's message of "Mon, 21 Sep 2009 13:26:57 +0200") References: <20090921112657.GW95398@hoeg.nl> Message-ID: <86ab0n2kdi.fsf@gmail.com> Ed Schouten writes: > Hi all, > > At the DevSummit in Cambridge we briefly discussed including tmux(1) in > the base system. We recently had window(1) there, but unfortunately > window(1) was a very limited tool, compared to tools like screen(1) and > tmux(1). Why tmux(1) and not screen(1)? Well, simple. The first has a > better license and very active maintenance. I think some simple tool like dtach(1) but with BSD-friendly license would be better suited for base system. And unlike mg(1) which is preferable to have in /rescue I don't think there is a reason to have tmux(1) in base other than avoiding ports. From brucec at muon.cran.org.uk Tue Sep 22 16:42:08 2009 From: brucec at muon.cran.org.uk (Bruce Cran) Date: Tue Sep 22 16:42:21 2009 Subject: tmux(1) in base In-Reply-To: <86y6o8kmiv.fsf@ds4.des.no> References: <20090921210159.2D4D51CC37@ptavv.es.net> <86y6o8kmiv.fsf@ds4.des.no> Message-ID: <20090922162500.GA29224@muon.cran.org.uk> On Mon, Sep 21, 2009 at 11:36:56PM +0200, Dag-Erling Sm??rgrav wrote: > "Kevin Oberman" writes: > > 1. Should such a tool be in the base system? > > We already have window(1). It has a number of features that screen(1) > and tmux(1) lack, but it can't detach. No we don't - it was removed at the start of June and moved to misc/window. -- Bruce Cran From dougb at FreeBSD.org Tue Sep 22 17:07:31 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Sep 22 17:07:38 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <20090922135435.36a3d40e@lazybytes.org> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> Message-ID: <4AB90448.9020706@FreeBSD.org> Sergey Vinogradov wrote: > The things in the base system I always wondered about are sendmail > and bind9. These are pretty heavy, and definitely are not used in every > single installation. Maybe someday I'll see sendmail and bind9 in ports > instead of base system. And yes, I know about WITHOUT_BIND= and > WITHOUT_SENDMAIL= :) For about the millionth time ... :) I would be perfectly happy to remove BIND, however most people want some or all of dig, host, or nslookup in the base, which means that about 60% or more of the BIND source code has to be there to allow that. From there it's a pretty simple leap to "let's build it all then because that's how we've always done it." The next-best thing would be to flip the knobs so that we're not building named and friends by default which I'm happy to do if people want it done, but no one ever comes up with a clear consensus to do it. Doug -- This .signature sanitized for your protection From gnemmi at gmail.com Tue Sep 22 17:14:14 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Sep 22 17:14:26 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <4AB90448.9020706@FreeBSD.org> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> Message-ID: <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> ... and what about sendmail?? couldn't it be easily replaced by DMA Regards Gonzalo On 9/22/09, Doug Barton wrote: > Sergey Vinogradov wrote: >> The things in the base system I always wondered about are sendmail >> and bind9. These are pretty heavy, and definitely are not used in every >> single installation. Maybe someday I'll see sendmail and bind9 in ports >> instead of base system. And yes, I know about WITHOUT_BIND= and >> WITHOUT_SENDMAIL= :) > > For about the millionth time ... :) > > I would be perfectly happy to remove BIND, however most people want > some or all of dig, host, or nslookup in the base, which means that > about 60% or more of the BIND source code has to be there to allow > that. From there it's a pretty simple leap to "let's build it all then > because that's how we've always done it." > > The next-best thing would be to flip the knobs so that we're not > building named and friends by default which I'm happy to do if people > want it done, but no one ever comes up with a clear consensus to do it. > > > Doug > > -- > > This .signature sanitized for your protection > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From peter at wemm.org Tue Sep 22 17:33:14 2009 From: peter at wemm.org (Peter Wemm) Date: Tue Sep 22 17:33:21 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> Message-ID: On Tue, Sep 22, 2009 at 10:14 AM, Gonzalo Nemmi wrote: > ... and what about sendmail?? > couldn't it be easily replaced by DMA > > Regards > Gonzalo I just went and had a quick at dma's info. It looks almost exactly like what I've been saying for ages we should have in the base instead of a heavyweight MTA. "It accepts mails from locally installed Mail User Agents (MUA) and delivers the mails either locally or to a remote destination. Remote delivery includes several features like TLS/SSL support and SMTP authentication." On the subject of host/dig/nslookup. We had an old 'host' and 'nslookup' that were replaced with bind's heavyweight versions. Perhaps those could be revived and refreshed? The functionality of 'host' that I care about is: peter@overcee[10:19AM]~-1177> host www.yahoo.com www.yahoo.com is an alias for www.wa1.b.yahoo.com. www.wa1.b.yahoo.com is an alias for www-real.wa1.b.yahoo.com. www-real.wa1.b.yahoo.com has address 209.131.36.158 peter@overcee[10:31AM]~-1178> host yahoo.com yahoo.com has address 209.191.93.53 yahoo.com has address 69.147.114.224 yahoo.com has address 209.131.36.159 yahoo.com mail is handled by 1 g.mx.mail.yahoo.com. yahoo.com mail is handled by 1 a.mx.mail.yahoo.com. yahoo.com mail is handled by 1 b.mx.mail.yahoo.com. yahoo.com mail is handled by 1 c.mx.mail.yahoo.com. yahoo.com mail is handled by 1 d.mx.mail.yahoo.com. yahoo.com mail is handled by 1 e.mx.mail.yahoo.com. yahoo.com mail is handled by 1 f.mx.mail.yahoo.com. peter@overcee[10:31AM]~-1179> host 209.131.36.158 158.36.131.209.in-addr.arpa domain name pointer f1.www.vip.sp1.yahoo.com. In other words, it's going to have to talk to the res_* functions in libc again instead of bind's replacement. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From sgk at troutmask.apl.washington.edu Tue Sep 22 17:35:17 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Tue Sep 22 17:36:15 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> Message-ID: <20090922173517.GB63149@troutmask.apl.washington.edu> On Tue, Sep 22, 2009 at 02:14:12PM -0300, Gonzalo Nemmi wrote: > ... and what about sendmail?? I suppose it doesn't matter to you that sendmail is actually maintained by Greg Shapiro, VP, CTO of Sendmail, Inc. > couldn't it be easily replaced by DMA If you don't want to build and use sendmail, see http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mail-changingmta.html -- Steve From peter at wemm.org Tue Sep 22 17:42:45 2009 From: peter at wemm.org (Peter Wemm) Date: Tue Sep 22 17:42:52 2009 Subject: tmux(1) in base In-Reply-To: <4AB7A708.5080209@FreeBSD.org> References: <20090921112657.GW95398@hoeg.nl> <200909211237.n8LCbkxV017364@hergotha.csail.mit.edu> <200909211309.n8LD9eTr017654@hergotha.csail.mit.edu> <20090921160955.GZ21946@elvis.mu.org> <4AB7A708.5080209@FreeBSD.org> Message-ID: On Mon, Sep 21, 2009 at 9:17 AM, Joel Dahl wrote: > Alfred Perlstein skrev: >> >> * Garrett Wollman [090921 06:10] wrote: >>> >>> In article <20090921130346.GY21946@elvis.mu.org> you write: >>> >>>> I think he already explained that it's supposedly much better than >>>> window(1) with a kinder license than screen(1). >>>> >>>> We really ought to ship with a screen(1)-like program. >>> >>> sudo pkg_add -r screen >>> >>> Problem solved. >> >> WORKS GREAT ESP WHEN NETWORK IS DOWN AND SOMEONE NEEDS MY HELP. >> >> WORKS AWESOME ON REALLY OLD MACHINES WHERE PACKAGES NO LONGER >> EXIST. >> >> Note: Apple, which cares more about a usable userland unix than >> we do at this time has screen installed in base as well. > > OpenBSD has tmux in base...and I've seen discussions on the NetBSD lists > about importing tmux (as a window(1) replacement) into NetBSD base as > well... ?:-) For what its worth, I'd like to see tmux in base. I'd use it. It won't get in the way of the screen users. Leave screen where it is. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From gnemmi at gmail.com Tue Sep 22 17:45:58 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Sep 22 17:46:04 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> Message-ID: <19e9a5dc0909221045q6dfa1affv4955b5b51107f514@mail.gmail.com> On 9/22/09, Peter Wemm wrote: > On Tue, Sep 22, 2009 at 10:14 AM, Gonzalo Nemmi wrote: >> ... and what about sendmail?? >> couldn't it be easily replaced by DMA >> >> Regards >> Gonzalo > > I just went and had a quick at dma's info. It looks almost exactly > like what I've been saying for ages we should have in the base instead > of a heavyweight MTA. > > "It accepts mails from locally > installed Mail User Agents (MUA) and delivers the mails either locally > or to a remote destination. Remote delivery includes several features > like TLS/SSL support and SMTP authentication." > Yes ... that's exactly I'm suggesting it. =D Regards Gonzalo From gnemmi at gmail.com Tue Sep 22 17:53:55 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Sep 22 17:54:01 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <20090922173517.GB63149@troutmask.apl.washington.edu> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> <20090922173517.GB63149@troutmask.apl.washington.edu> Message-ID: <19e9a5dc0909221053r4ada92bege718e37aa575e0de@mail.gmail.com> On 9/22/09, Steve Kargl wrote: > On Tue, Sep 22, 2009 at 02:14:12PM -0300, Gonzalo Nemmi wrote: >> ... and what about sendmail?? > > I suppose it doesn't matter to you that sendmail is > actually maintained by Greg Shapiro, VP, CTO of > Sendmail, Inc. No, not really ... >> couldn't it be easily replaced by DMA > > If you don't want to build and use sendmail, see > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mail-changingmta.html With all due respect, I already know that .. it's pretty clear in the different manuals, hanbooks and how-ro's ... and that's exactly why I never asked how can I remove sendmail and replace it with dma .. the question was more inclined in the way: why such a heavywheight (which is what a lot of users seem to be saying, and I agree with them) when we could do just as well with dma (let alone the fact that we could then cooperate with DragonFly, creating synergy, advancing toghether towards the same goal amongst a plenty of other advantages). Best Regards Gonzalo From dougb at FreeBSD.org Tue Sep 22 18:55:53 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Sep 22 18:56:06 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <19e9a5dc0909221053r4ada92bege718e37aa575e0de@mail.gmail.com> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> <20090922173517.GB63149@troutmask.apl.washington.edu> <19e9a5dc0909221053r4ada92bege718e37aa575e0de@mail.gmail.com> Message-ID: <4AB91DAA.5010000@FreeBSD.org> Gonzalo Nemmi wrote: > With all due respect, I already know that .. it's pretty clear in the > different manuals, hanbooks and how-ro's ... and that's exactly why I > never asked how can I remove sendmail and replace it with dma .. the > question was more inclined in the way: why such a heavywheight (which > is what a lot of users seem to be saying, and I agree with them) when > we could do just as well with dma So do it already. :) A lot of people have talked about this, but no one has put code where their mouth is. Create a POC and post it to -arch, then we have something concrete to discuss. And please, don't bother with the "But I don't want to do the work if it isn't going to be accepted into the base" argument. There are way more than enough people whinging about this topic that your work will have an appreciative audience, which is all the reward we get around here. > (let alone the fact that we could > then cooperate with DragonFly, creating synergy, advancing toghether > towards the same goal amongst a plenty of other advantages). While those are nice words I don't think they have any meaning in the real world. We're dealing with a technical issue, we need to keep the discussion on technical terms. -- This .signature sanitized for your protection From gshapiro at freebsd.org Tue Sep 22 20:04:53 2009 From: gshapiro at freebsd.org (Gregory Shapiro) Date: Tue Sep 22 20:05:05 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <20090922173517.GB63149@troutmask.apl.washington.edu> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> <20090922173517.GB63149@troutmask.apl.washington.edu> Message-ID: <20090922200449.GL19207@rugsucker.local> > I suppose it doesn't matter to you that sendmail is actually > maintained by Greg Shapiro, VP, CTO of Sendmail, Inc. While I appreciate the vote of confidence, it doesn't, and it shouldn't. I'll continue to maintain sendmail in the base as long as it is welcome there. If the project wants it moved out, that is not up to me (though I hope it stays). I haven't spent a lot of time looking at DMA, but some requirements that pop to mind for it to be a replacement would be things like accepting local mail via SMTP (e.g., for MUAs which use SMTP submission) and supporting STARTTLS and SMTP AUTH for talking to the upstream MTA. From gnemmi at gmail.com Tue Sep 22 20:29:28 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Sep 22 20:29:40 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <20090922200449.GL19207@rugsucker.local> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> <20090922173517.GB63149@troutmask.apl.washington.edu> <20090922200449.GL19207@rugsucker.local> Message-ID: <19e9a5dc0909221329j5757c3f7kc23e94ea8f26a05@mail.gmail.com> On 9/22/09, Gregory Shapiro wrote: >> I suppose it doesn't matter to you that sendmail is actually >> maintained by Greg Shapiro, VP, CTO of Sendmail, Inc. > > While I appreciate the vote of confidence, it doesn't, and it shouldn't. > I'll continue to maintain sendmail in the base as long as it is welcome > there. If the project wants it moved out, that is not up to me (though > I hope it stays). > > I haven't spent a lot of time looking at DMA, but some requirements that > pop to mind for it to be a replacement would be things like accepting > local mail via SMTP (e.g., for MUAs which use SMTP submission) and > supporting STARTTLS and SMTP AUTH for talking to the upstream MTA. Dear Mr. Gregory Shapiro: I'm writing this letter to let you know that I have nothing personal against either your person, your professional work, your contributions to the FreeBSD project, your personal and professional merits or anything at all. I was prompt with an dubiously honest question and I replied with an honest answer, as I know no other way, and yet still stand in the belief that the use of names as means to declare any authority, be it moral or otherwise, constitutes no truth nor does any good to reason. With that beign said, I hereby show my respect and thank you for your invaluable contribution to the FreeBSD project, as well as I thank you for clarifying me "why should sendmail remain in base", which is something that no one has ever done this far. My apologies for the inconveniences or offenses I might unwittingly have caused you. Sincerily yours Gonzalo Ra?l Nemmi From gshapiro at gshapiro.net Tue Sep 22 20:44:00 2009 From: gshapiro at gshapiro.net (Gregory Shapiro) Date: Tue Sep 22 20:44:33 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <19e9a5dc0909221329j5757c3f7kc23e94ea8f26a05@mail.gmail.com> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> <20090922173517.GB63149@troutmask.apl.washington.edu> <20090922200449.GL19207@rugsucker.local> <19e9a5dc0909221329j5757c3f7kc23e94ea8f26a05@mail.gmail.com> Message-ID: <20090922204356.GM19207@rugsucker.local> > My apologies for the inconveniences or offenses I might unwittingly > have caused you. Oh no, none necessary at all and I am sorry if my reply to Steve was misinterpreted. I wanted to both thank Steve for the recognition and also agree with you -- who I am doesn't enter into the picture, all that matters is what is best for the project. The only other factor that enters into the decision making is if sendmail is being actively and properly maintained. From louie at transsys.com Tue Sep 22 20:54:57 2009 From: louie at transsys.com (Louis Mamakos) Date: Tue Sep 22 20:55:03 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <4AB90448.9020706@FreeBSD.org> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> Message-ID: <8A3D6B19-8AD6-4222-8C26-4DF87D0709C6@transsys.com> On Sep 22, 2009, at 1:07 PM, Doug Barton wrote: > > I would be perfectly happy to remove BIND, however most people want > some or all of dig, host, or nslookup in the base, which means that > about 60% or more of the BIND source code has to be there to allow > that. From there it's a pretty simple leap to "let's build it all then > because that's how we've always done it." > > The next-best thing would be to flip the knobs so that we're not > building named and friends by default which I'm happy to do if people > want it done, but no one ever comes up with a clear consensus to do > it. Ideally, FreeBSD out-of-the-box ought to have a caching DNS server as part of the base system. I don't understand myself why people don't run caching name servers on every Internet-connected host, and want to rely on some other external entity. Heck, I run 'em on my nanobad based systems on Soekris boxes; the footprint really isn't that large. BIND serves this purpose adequately, though I'm sure that there are endless other possibilities better/faster/smaller/cheaper/prettier.. louie From gnemmi at gmail.com Tue Sep 22 21:11:39 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Sep 22 21:11:46 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <4AB91DAA.5010000@FreeBSD.org> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> <20090922173517.GB63149@troutmask.apl.washington.edu> <19e9a5dc0909221053r4ada92bege718e37aa575e0de@mail.gmail.com> <4AB91DAA.5010000@FreeBSD.org> Message-ID: <19e9a5dc0909221411n1486cb80x220384b37daee921@mail.gmail.com> On 9/22/09, Doug Barton wrote: > Gonzalo Nemmi wrote: > >> With all due respect, I already know that .. it's pretty clear in the >> different manuals, hanbooks and how-ro's ... and that's exactly why I >> never asked how can I remove sendmail and replace it with dma .. the >> question was more inclined in the way: why such a heavywheight (which >> is what a lot of users seem to be saying, and I agree with them) when >> we could do just as well with dma > > So do it already. :) A lot of people have talked about this, but no > one has put code where their mouth is. Create a POC and post it to > -arch, then we have something concrete to discuss. And please, don't > bother with the "But I don't want to do the work if it isn't going to > be accepted into the base" argument. There are way more than enough > people whinging about this topic that your work will have an > appreciative audience, which is all the reward we get around here. Dear Doug: Those words were just an explanation to Steve Kargl's misleading interpretation of my former e-mail. >> (let alone the fact that we could >> then cooperate with DragonFly, creating synergy, advancing toghether >> towards the same goal amongst a plenty of other advantages). > > While those are nice words I don't think they have any meaning in the > real world. We're dealing with a technical issue, we need to keep the > discussion on technical terms. Oh they do .. believe me ... specially to me, the paying customer =) Regards Gonzalo From sgk at troutmask.apl.washington.edu Tue Sep 22 21:26:51 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Tue Sep 22 21:27:03 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <19e9a5dc0909221411n1486cb80x220384b37daee921@mail.gmail.com> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> <20090922173517.GB63149@troutmask.apl.washington.edu> <19e9a5dc0909221053r4ada92bege718e37aa575e0de@mail.gmail.com> <4AB91DAA.5010000@FreeBSD.org> <19e9a5dc0909221411n1486cb80x220384b37daee921@mail.gmail.com> Message-ID: <20090922212650.GA84817@troutmask.apl.washington.edu> On Tue, Sep 22, 2009 at 06:11:37PM -0300, Gonzalo Nemmi wrote: > On 9/22/09, Doug Barton wrote: > > Gonzalo Nemmi wrote: > > > >> With all due respect, I already know that .. it's pretty clear in the > >> different manuals, hanbooks and how-ro's ... and that's exactly why I > >> never asked how can I remove sendmail and replace it with dma .. the > >> question was more inclined in the way: why such a heavywheight (which > >> is what a lot of users seem to be saying, and I agree with them) when > >> we could do just as well with dma > > > > So do it already. :) A lot of people have talked about this, but no > > one has put code where their mouth is. Create a POC and post it to > > -arch, then we have something concrete to discuss. And please, don't > > bother with the "But I don't want to do the work if it isn't going to > > be accepted into the base" argument. There are way more than enough > > people whinging about this topic that your work will have an > > appreciative audience, which is all the reward we get around here. > > Dear Doug: > > Those words were just an explanation to Steve Kargl's misleading > interpretation of my former e-mail. > My interpretation was not misleading. If anything my comment was informative because there was no indication in your post that you knew the history and continued maintenance of sendmail nor did you indicate that you knew how to replace sendmail via the Handbook's description. -- Steve From sgk at troutmask.apl.washington.edu Tue Sep 22 21:31:28 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Tue Sep 22 21:31:34 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <19e9a5dc0909221329j5757c3f7kc23e94ea8f26a05@mail.gmail.com> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> <20090922173517.GB63149@troutmask.apl.washington.edu> <20090922200449.GL19207@rugsucker.local> <19e9a5dc0909221329j5757c3f7kc23e94ea8f26a05@mail.gmail.com> Message-ID: <20090922213127.GB84817@troutmask.apl.washington.edu> On Tue, Sep 22, 2009 at 05:29:25PM -0300, Gonzalo Nemmi wrote: > On 9/22/09, Gregory Shapiro wrote: > >> I suppose it doesn't matter to you that sendmail is actually > >> maintained by Greg Shapiro, VP, CTO of Sendmail, Inc. > > > > While I appreciate the vote of confidence, it doesn't, and it shouldn't. > > I'll continue to maintain sendmail in the base as long as it is welcome > > there. If the project wants it moved out, that is not up to me (though > > I hope it stays). > > > > I haven't spent a lot of time looking at DMA, but some requirements that > > pop to mind for it to be a replacement would be things like accepting > > local mail via SMTP (e.g., for MUAs which use SMTP submission) and > > supporting STARTTLS and SMTP AUTH for talking to the upstream MTA. > > Dear Mr. Gregory Shapiro: > > I'm writing this letter to let you know that I have nothing personal > against either your person, your professional work, your contributions > to the FreeBSD project, your personal and professional merits or > anything at all. > > I was prompt with an dubiously honest question and I replied with an > honest answer, as I know no other way, and yet still stand in the > belief that the use of names as means to declare any authority, be it > moral or otherwise, constitutes no truth nor does any good to reason. > Then you completely missed the point of my response. sendmail is being maintained the people that actual wrote the code. If dma replaces sendmail, will the authors of dma become FreeBSD committers and maintain dma in the same manner that sendmail has been maintained. -- Steve From sgk at troutmask.apl.washington.edu Tue Sep 22 21:34:52 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Tue Sep 22 21:35:26 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <20090922204356.GM19207@rugsucker.local> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> <20090922173517.GB63149@troutmask.apl.washington.edu> <20090922200449.GL19207@rugsucker.local> <19e9a5dc0909221329j5757c3f7kc23e94ea8f26a05@mail.gmail.com> <20090922204356.GM19207@rugsucker.local> Message-ID: <20090922213451.GC84817@troutmask.apl.washington.edu> On Tue, Sep 22, 2009 at 01:43:56PM -0700, Gregory Shapiro wrote: > > My apologies for the inconveniences or offenses I might unwittingly > > have caused you. > > Oh no, none necessary at all and I am sorry if my reply to Steve was > misinterpreted. I wanted to both thank Steve for the recognition and > also agree with you -- who I am doesn't enter into the picture, all that > matters is what is best for the project. The only other factor that > enters into the decision making is if sendmail is being actively and > properly maintained. Your last line was my point, which apparentily has been missed. sendmail is actively maintained by you (and Sendmail, Inc.). If sendmail is replaced by dma, will it receive the same level of care? I guess this is considered to be a dubious concern by some. -- Steve From des at des.no Tue Sep 22 21:46:49 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Sep 22 21:46:56 2009 Subject: tmux(1) in base In-Reply-To: <37B47737-E4A4-4CF3-9DAA-B0F0A4CC8901@van-laarhoven.org> (Nick Hibma's message of "Tue, 22 Sep 2009 13:06:42 +0200") References: <20090921112657.GW95398@hoeg.nl> <4AB7ED76.5010406@FreeBSD.org> <20090922082344.GA64877@mech-cluster241.men.bris.ac.uk> <37B47737-E4A4-4CF3-9DAA-B0F0A4CC8901@van-laarhoven.org> Message-ID: <86d45i1wl3.fsf@ds4.des.no> Nick Hibma writes: > Our package system is a tremendous asset, and wholeheartedly agree > with Doug on this. So my vote is now a -1. Not that anyone cares. Having seen how it turned out, I'd like to vote -50,000,000 on this whole discussion... DES -- Dag-Erling Sm?rgrav - des@des.no From gnemmi at gmail.com Tue Sep 22 21:59:39 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Sep 22 22:00:17 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <20090922212650.GA84817@troutmask.apl.washington.edu> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> <20090922173517.GB63149@troutmask.apl.washington.edu> <19e9a5dc0909221053r4ada92bege718e37aa575e0de@mail.gmail.com> <4AB91DAA.5010000@FreeBSD.org> <19e9a5dc0909221411n1486cb80x220384b37daee921@mail.gmail.com> <20090922212650.GA84817@troutmask.apl.washington.edu> Message-ID: <19e9a5dc0909221459q5095f29qcd0c09886a7a4ee3@mail.gmail.com> On 9/22/09, Steve Kargl wrote: > On Tue, Sep 22, 2009 at 06:11:37PM -0300, Gonzalo Nemmi wrote: >> On 9/22/09, Doug Barton wrote: >> > Gonzalo Nemmi wrote: >> > >> >> With all due respect, I already know that .. it's pretty clear in the >> >> different manuals, hanbooks and how-ro's ... and that's exactly why I >> >> never asked how can I remove sendmail and replace it with dma .. the >> >> question was more inclined in the way: why such a heavywheight (which >> >> is what a lot of users seem to be saying, and I agree with them) when >> >> we could do just as well with dma >> > >> > So do it already. :) A lot of people have talked about this, but no >> > one has put code where their mouth is. Create a POC and post it to >> > -arch, then we have something concrete to discuss. And please, don't >> > bother with the "But I don't want to do the work if it isn't going to >> > be accepted into the base" argument. There are way more than enough >> > people whinging about this topic that your work will have an >> > appreciative audience, which is all the reward we get around here. >> >> Dear Doug: >> >> Those words were just an explanation to Steve Kargl's misleading >> interpretation of my former e-mail. >> > > My interpretation was not misleading. If anything my comment > was informative because there was no indication in your post > that you knew the history and continued maintenance of sendmail > nor did you indicate that you knew how to replace sendmail via > the Handbook's description. Yet you assumed I didn't know any of them, took no care in finding out the answer to at least even one of your presumptions and decided that the best way to find out was to throw Shapiro's name on me and tell me to RTFM instead of coming up with a straight answer to a straight question?. So much for the Occam's razor principle ... Anyways .. this is way OT and I'm no longer willing to discuss it. Regards Gonzalo From gnemmi at gmail.com Tue Sep 22 22:05:35 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Sep 22 22:05:42 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <20090922213127.GB84817@troutmask.apl.washington.edu> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> <20090922173517.GB63149@troutmask.apl.washington.edu> <20090922200449.GL19207@rugsucker.local> <19e9a5dc0909221329j5757c3f7kc23e94ea8f26a05@mail.gmail.com> <20090922213127.GB84817@troutmask.apl.washington.edu> Message-ID: <19e9a5dc0909221505k3d55d070u741d86e03d2316a6@mail.gmail.com> On 9/22/09, Steve Kargl wrote: > On Tue, Sep 22, 2009 at 05:29:25PM -0300, Gonzalo Nemmi wrote: >> On 9/22/09, Gregory Shapiro wrote: >> >> I suppose it doesn't matter to you that sendmail is actually >> >> maintained by Greg Shapiro, VP, CTO of Sendmail, Inc. >> > >> > While I appreciate the vote of confidence, it doesn't, and it shouldn't. >> > I'll continue to maintain sendmail in the base as long as it is welcome >> > there. If the project wants it moved out, that is not up to me (though >> > I hope it stays). >> > >> > I haven't spent a lot of time looking at DMA, but some requirements that >> > pop to mind for it to be a replacement would be things like accepting >> > local mail via SMTP (e.g., for MUAs which use SMTP submission) and >> > supporting STARTTLS and SMTP AUTH for talking to the upstream MTA. >> >> Dear Mr. Gregory Shapiro: >> >> I'm writing this letter to let you know that I have nothing personal >> against either your person, your professional work, your contributions >> to the FreeBSD project, your personal and professional merits or >> anything at all. >> >> I was prompt with an dubiously honest question and I replied with an >> honest answer, as I know no other way, and yet still stand in the >> belief that the use of names as means to declare any authority, be it >> moral or otherwise, constitutes no truth nor does any good to reason. >> > > Then you completely missed the point of my response. sendmail > is being maintained the people that actual wrote the code. If > dma replaces sendmail, will the authors of dma become FreeBSD > committers and maintain dma in the same manner that sendmail > has been maintained. Then you completely missed _my_ point which is the same point other posters have been making: so much whining for (tiny) tmux when we still have (huge) sendmail in base? to turn the discussion into yours (who's gonna maintain dma should we replace sendmail?). Regards Gonzalo From des at des.no Tue Sep 22 22:26:07 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Sep 22 22:26:19 2009 Subject: tmux(1) in base In-Reply-To: <20090922135435.36a3d40e@lazybytes.org> (Sergey Vinogradov's message of "Tue, 22 Sep 2009 13:54:35 +0400") References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> Message-ID: <864oqu1urm.fsf@ds4.des.no> Sergey Vinogradov writes: > Despite the zsh(1) has appropriate license, it needs autotools and > iconv (both GPL AFAIK), so it's hard to include in the base system. > The things in the base system I always wondered about are sendmail > and bind9. These are pretty heavy, and definitely are not used in every > single installation. Maybe someday I'll see sendmail and bind9 in ports > instead of base system. And yes, I know about WITHOUT_BIND= and > WITHOUT_SENDMAIL= :) 1) Even in sh mode, zsh is not sufficiently POSIX-compliant to replace our /bin/sh (and I say this as the maintainer of the zsh port) 2) Sendmail is used at least twice a day + once a week + once a month on every single FreeBSD installation in the world except those where the admin has intentionally installed and configured another MTA. 3) Both BIND and Sendmail have strong historical ties to BSD, and a lot of users would be very surprised to find them missing from the next release. 4) The FreeBSD project has strong ties to and good working relationships with the people and organizations who write and maintain BIND and Sendmail, ensuring that they are well integrated into our codebase, that any concerns we should have about them are given serious consideration, that we always receive ample advance notification of any know problems, etc. 5) Both BIND and Sendmail are mature, robust, highly regarded, actively maintained pieces of software with strong developer and user communities. Unbound, DMA, or whatever it is you would replace them with can only dream of enjoying a fraction of the respect that BIND and Sendmail command in the industry. 6) This discussion comes up with depressing regularity. The arguments on both sides are always the same, as is the conclusion: you can have BIND and Sendmail when you pry them out of Beastie's cold, dead fingers. Now go write some code. DES -- Dag-Erling Sm?rgrav - des@des.no From alfred at freebsd.org Tue Sep 22 22:50:30 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Sep 22 22:50:37 2009 Subject: tmux(1) in base In-Reply-To: <86d45i1wl3.fsf@ds4.des.no> References: <20090921112657.GW95398@hoeg.nl> <4AB7ED76.5010406@FreeBSD.org> <20090922082344.GA64877@mech-cluster241.men.bris.ac.uk> <37B47737-E4A4-4CF3-9DAA-B0F0A4CC8901@van-laarhoven.org> <86d45i1wl3.fsf@ds4.des.no> Message-ID: <20090922225029.GP21946@elvis.mu.org> * Dag-Erling Sm??rgrav [090922 14:47] wrote: > Nick Hibma writes: > > Our package system is a tremendous asset, and wholeheartedly agree > > with Doug on this. So my vote is now a -1. Not that anyone cares. > > Having seen how it turned out, I'd like to vote -50,000,000 on this > whole discussion... Surely we're not done until someone suggests replacing /bin/sh with bash, amirite? -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From gshapiro at gshapiro.net Wed Sep 23 00:49:20 2009 From: gshapiro at gshapiro.net (Gregory Shapiro) Date: Wed Sep 23 00:49:33 2009 Subject: BIND in the base (Was: Re: tmux(1) in base) In-Reply-To: <20090922213451.GC84817@troutmask.apl.washington.edu> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <4AB90448.9020706@FreeBSD.org> <19e9a5dc0909221014o14e88c96ubf32142b85d781d@mail.gmail.com> <20090922173517.GB63149@troutmask.apl.washington.edu> <20090922200449.GL19207@rugsucker.local> <19e9a5dc0909221329j5757c3f7kc23e94ea8f26a05@mail.gmail.com> <20090922204356.GM19207@rugsucker.local> <20090922213451.GC84817@troutmask.apl.washington.edu> Message-ID: <20090923004915.GQ19207@rugsucker.local> > If sendmail is replaced by dma, will it receive the same level of > care? I guess this is considered to be a dubious concern by some. It is a valid concern, but not one I can comment on (i.e., I would not be able to maintain it). From olli at lurza.secnetix.de Wed Sep 23 08:56:31 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Sep 23 08:56:37 2009 Subject: BIND in the base In-Reply-To: <19e9a5dc0909221505k3d55d070u741d86e03d2316a6@mail.gmail.com> Message-ID: <200909230856.n8N8uDYP003815@lurza.secnetix.de> Gonzalo Nemmi wrote: > Then you completely missed _my_ point which is the same point other > posters have been making: so much whining for (tiny) tmux when we > still have (huge) sendmail in base? to turn the discussion into yours > (who's gonna maintain dma should we replace sendmail?). You're saying tmux is "tiny" and sendmail is "huge" -- Have you actually looked at the sizes? tmux is 1 MB, while the sendmail source code are 2 MB. Sure, it's a difference, but not an order of magnitude. FWIW, dma cannot replace sendmail because it's still missing some important features, such as .forward. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper." -- Ralf Hildebrandt From olli at lurza.secnetix.de Wed Sep 23 09:06:38 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Sep 23 09:06:44 2009 Subject: BIND in the base In-Reply-To: Message-ID: <200909230906.n8N96KZU004384@lurza.secnetix.de> Peter Wemm wrote: > On the subject of host/dig/nslookup. We had an old 'host' and > 'nslookup' that were replaced with bind's heavyweight versions. > Perhaps those could be revived and refreshed? > > The functionality of 'host' that I care about is: > [...] The functionality of 'host' (and 'dig') that I care about is the fact that it ignores /etc/hosts and nsswitch.conf and always uses DNS. This feature has been invaluable for me for debugging DNS issues. BTW, it's a pity window(1) was removed from base. The removal breaks several scripts of mine, particularly ones that are specifically designed to run without any ports installed. Please let BIND stay. And sendmail, too. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd It's trivial to make fun of Microsoft products, but it takes a real man to make them work, and a God to make them do anything useful. From boogie at lazybytes.org Wed Sep 23 09:20:21 2009 From: boogie at lazybytes.org (Sergey Vinogradov) Date: Wed Sep 23 09:20:41 2009 Subject: tmux(1) in base In-Reply-To: <864oqu1urm.fsf@ds4.des.no> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <864oqu1urm.fsf@ds4.des.no> Message-ID: <20090923132036.57767deb@lazybytes.org> ? Wed, 23 Sep 2009 00:26:05 +0200 Dag-Erling Sm?rgrav ?????: > Sergey Vinogradov writes: > > Despite the zsh(1) has appropriate license, it needs autotools and > > iconv (both GPL AFAIK), so it's hard to include in the base system. > > The things in the base system I always wondered about are sendmail > > and bind9. These are pretty heavy, and definitely are not used in > > every single installation. Maybe someday I'll see sendmail and > > bind9 in ports instead of base system. And yes, I know about > > WITHOUT_BIND= and WITHOUT_SENDMAIL= :) > > 1) Even in sh mode, zsh is not sufficiently POSIX-compliant to replace > our /bin/sh (and I say this as the maintainer of the zsh port) I think I've made my point unclear: I fully understand that, and I don't propose zsh(1) replacing sh(1). I just think it would be handy to have zsh(1) in the base system. Not replacing sh(1), but as one more piece of software. -- wbr, Boo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090923/15b32082/signature.pgp From julian at elischer.org Wed Sep 23 09:40:58 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 23 09:41:04 2009 Subject: BIND in the base In-Reply-To: <200909230906.n8N96KZU004384@lurza.secnetix.de> References: <200909230906.n8N96KZU004384@lurza.secnetix.de> Message-ID: <4AB9E9F0.3020500@elischer.org> Oliver Fromme wrote: > Peter Wemm wrote: > > On the subject of host/dig/nslookup. We had an old 'host' and > > 'nslookup' that were replaced with bind's heavyweight versions. > > Perhaps those could be revived and refreshed? > > > > The functionality of 'host' that I care about is: > > [...] > > The functionality of 'host' (and 'dig') that I care about > is the fact that it ignores /etc/hosts and nsswitch.conf > and always uses DNS. This feature has been invaluable > for me for debugging DNS issues. > > BTW, it's a pity window(1) was removed from base. > The removal breaks several scripts of mine, particularly > ones that are specifically designed to run without any > ports installed. Actually I had to go look at CVS (I couldn't work out how to get svn to tell me who removed it) to see who took it out and when. I don't recall any discussion of this, and while it may have been the right answer, I think it was poorly handled. It seems it was pretty much a single person's decision, and I object to that as it did go against POLA. It should have been discussed more at least. > > Please let BIND stay. And sendmail, too. > > Best regards > Oliver > From svein-listmail at stillbilde.net Wed Sep 23 09:48:00 2009 From: svein-listmail at stillbilde.net (Svein Skogen (listmail account)) Date: Wed Sep 23 09:48:14 2009 Subject: tmux(1) in base In-Reply-To: <20090923132036.57767deb@lazybytes.org> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <864oqu1urm.fsf@ds4.des.no> <20090923132036.57767deb@lazybytes.org> Message-ID: <4AB9EAE7.6090108@stillbilde.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sergey Vinogradov wrote: > ? Wed, 23 Sep 2009 00:26:05 +0200 > Dag-Erling Sm?rgrav ?????: > >> Sergey Vinogradov writes: >>> Despite the zsh(1) has appropriate license, it needs autotools and >>> iconv (both GPL AFAIK), so it's hard to include in the base system. >>> The things in the base system I always wondered about are sendmail >>> and bind9. These are pretty heavy, and definitely are not used in >>> every single installation. Maybe someday I'll see sendmail and >>> bind9 in ports instead of base system. And yes, I know about >>> WITHOUT_BIND= and WITHOUT_SENDMAIL= :) >> 1) Even in sh mode, zsh is not sufficiently POSIX-compliant to replace >> our /bin/sh (and I say this as the maintainer of the zsh port) > I think I've made my point unclear: I fully understand that, and I > don't propose zsh(1) replacing sh(1). I just think it would be handy to > have zsh(1) in the base system. Not replacing sh(1), but as one > more piece of software. Wouldn't that bring back (among others) perl into the base? I seem to remember there was some effort spent on removing that a while ago... //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg ?stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq56uYACgkQODUnwSLUlKTmowCgna2UmnZCCT/9xYFYCase10Ua 3qcAnjI5MnTA3aL35OTc9uxCOcPRaUFX =da5r -----END PGP SIGNATURE----- From boogie at lazybytes.org Wed Sep 23 09:50:09 2009 From: boogie at lazybytes.org (Sergey Vinogradov) Date: Wed Sep 23 09:50:16 2009 Subject: tmux(1) in base In-Reply-To: <4AB9EAE7.6090108@stillbilde.net> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <864oqu1urm.fsf@ds4.des.no> <20090923132036.57767deb@lazybytes.org> <4AB9EAE7.6090108@stillbilde.net> Message-ID: <20090923135029.69a016f8@lazybytes.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ? Wed, 23 Sep 2009 11:31:19 +0200 "Svein Skogen (listmail account)" ?????: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Sergey Vinogradov wrote: > > ? Wed, 23 Sep 2009 00:26:05 +0200 > > Dag-Erling Sm?rgrav ?????: > > > >> Sergey Vinogradov writes: > >>> Despite the zsh(1) has appropriate license, it needs autotools and > >>> iconv (both GPL AFAIK), so it's hard to include in the base > >>> system. The things in the base system I always wondered about are > >>> sendmail and bind9. These are pretty heavy, and definitely are > >>> not used in every single installation. Maybe someday I'll see > >>> sendmail and bind9 in ports instead of base system. And yes, I > >>> know about WITHOUT_BIND= and WITHOUT_SENDMAIL= :) > >> 1) Even in sh mode, zsh is not sufficiently POSIX-compliant to > >> replace our /bin/sh (and I say this as the maintainer of the zsh > >> port) > > I think I've made my point unclear: I fully understand that, and I > > don't propose zsh(1) replacing sh(1). I just think it would be > > handy to have zsh(1) in the base system. Not replacing sh(1), but > > as one more piece of software. > > Wouldn't that bring back (among others) perl into the base? I seem to > remember there was some effort spent on removing that a while ago... > > //Svein > Well, zsh(1) doesn't have perl as run, or build dependency directly. However, autoconf, which is involved in zsh(1) build process does depend on perl. - -- wbr, Boo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkq572UACgkQCt8hfbw1GpYv/ACdHC4fvjDPgNhLXsB6UAD6RPFk YYQAn2S/jsxSH6aitLwmNvqube6oIS5P =5wZh -----END PGP SIGNATURE----- From ed at 80386.nl Wed Sep 23 17:01:44 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Sep 23 17:02:16 2009 Subject: BIND in the base In-Reply-To: <4AB9E9F0.3020500@elischer.org> References: <200909230906.n8N96KZU004384@lurza.secnetix.de> <4AB9E9F0.3020500@elischer.org> Message-ID: <51C55D74-F18B-4356-811E-13B4AA938D48@80386.nl> It wasn't a single person decision. Trhodes wanted to maintain it. After some discussion we agreed having it in ports would make it easier for tom to maintain. -- Ed Schouten (from iPod) WWW: http://80386.nl/ On 23 sep 2009, at 11:27, Julian Elischer wrote: > Oliver Fromme wrote: >> Peter Wemm wrote: >> > On the subject of host/dig/nslookup. We had an old 'host' and >> > 'nslookup' that were replaced with bind's heavyweight versions. >> > Perhaps those could be revived and refreshed? >> > > The functionality of 'host' that I care about is: >> > [...] >> The functionality of 'host' (and 'dig') that I care about >> is the fact that it ignores /etc/hosts and nsswitch.conf >> and always uses DNS. This feature has been invaluable >> for me for debugging DNS issues. >> BTW, it's a pity window(1) was removed from base. >> The removal breaks several scripts of mine, particularly >> ones that are specifically designed to run without any >> ports installed. > > Actually I had to go look at CVS (I couldn't work out how to get > svn to tell me who removed it) to see who took it out and when. > > I don't recall any discussion of this, and while it may have been > the right answer, I think it was poorly handled. > > It seems it was pretty much a single person's decision, > and I object to that as it did go against POLA. > It should have been discussed more at least. > >> Please let BIND stay. And sendmail, too. >> Best regards >> Oliver > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch- > unsubscribe@freebsd.org" > From julian at elischer.org Wed Sep 23 17:22:42 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 23 17:22:49 2009 Subject: BIND in the base In-Reply-To: <51C55D74-F18B-4356-811E-13B4AA938D48@80386.nl> References: <200909230906.n8N96KZU004384@lurza.secnetix.de> <4AB9E9F0.3020500@elischer.org> <51C55D74-F18B-4356-811E-13B4AA938D48@80386.nl> Message-ID: <4ABA5965.4090802@elischer.org> Ed Schouten wrote: > It wasn't a single person decision. Trhodes wanted to maintain it. After > some discussion we agreed having it in ports would make it easier for > tom to maintain. > ok so it was 2 people. he maintains it and we all lose it.. odd. From ed at 80386.nl Wed Sep 23 17:38:02 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Sep 23 17:38:09 2009 Subject: BIND in the base In-Reply-To: <4ABA5965.4090802@elischer.org> References: <200909230906.n8N96KZU004384@lurza.secnetix.de> <4AB9E9F0.3020500@elischer.org> <51C55D74-F18B-4356-811E-13B4AA938D48@80386.nl> <4ABA5965.4090802@elischer.org> Message-ID: <20090923173801.GI95398@hoeg.nl> * Julian Elischer wrote: > ok so it was 2 people. > > he maintains it and we all lose it.. odd. I still miss pcvt(4). -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090923/0180787e/attachment.pgp From rink at FreeBSD.org Wed Sep 23 18:35:47 2009 From: rink at FreeBSD.org (Rink Springer) Date: Wed Sep 23 18:35:54 2009 Subject: BIND in the base In-Reply-To: <20090923173801.GI95398@hoeg.nl> References: <200909230906.n8N96KZU004384@lurza.secnetix.de> <4AB9E9F0.3020500@elischer.org> <51C55D74-F18B-4356-811E-13B4AA938D48@80386.nl> <4ABA5965.4090802@elischer.org> <20090923173801.GI95398@hoeg.nl> Message-ID: <20090923181812.GA14098@rink.nu> On Wed, Sep 23, 2009 at 07:38:01PM +0200, Ed Schouten wrote: > I still miss pcvt(4). Not a day passes without me missing Alpha.. [*] [*] This is not serious, but it should illustrate the point: no one stepped up, and appearantly no one bothered to try window(1) but suddenly it's terrible that it was nuked months ago... Bottomline: can we PLEASE drop this thread and get to coding? Or in terms people likely will understand more, 'kill -SIGSTOP $thread'. Regards, -- Rink P.W. Springer - http://rink.nu "Beauty often seduces us on the road to truth." - Dr. Wilson From peterjeremy at acm.org Wed Sep 23 20:59:28 2009 From: peterjeremy at acm.org (Peter Jeremy) Date: Wed Sep 23 20:59:34 2009 Subject: tmux(1) in base In-Reply-To: <4AB9EAE7.6090108@stillbilde.net> References: <20090921112657.GW95398@hoeg.nl> <20090922135435.36a3d40e@lazybytes.org> <864oqu1urm.fsf@ds4.des.no> <20090923132036.57767deb@lazybytes.org> <4AB9EAE7.6090108@stillbilde.net> Message-ID: <20090923185816.GB26192@server.vk2pj.dyndns.org> I'm particurly impressed at the striped red and blue paint that has been liberally applied to the shed. On 2009-Sep-23 11:31:19 +0200, "Svein Skogen (listmail account)" wrote: >Sergey Vinogradov wrote: >> don't propose zsh(1) replacing sh(1). I just think it would be handy to >> have zsh(1) in the base system. Not replacing sh(1), but as one >> more piece of software. I personally use zsh as my interactive shell but I don't think it belongs in the base system. IMHO, the base system only needs a single, POSIX-compliant shell - so it is already over-endowed. >Wouldn't that bring back (among others) perl into the base? I seem to >remember there was some effort spent on removing that a while ago... There were two main reasons for removing perl: 1) Perl was undergoing rapid development at a rate that was not compatible with the FreeBSD release schedule - so the base version of perl was out-of-date. 2) The FreeBSD base system must be able to be cross-built (this is needed to support upgrading even within the same architecture). Perl is not intended to be cross-built and the effort involved in shoe-horning it into the buildworld process was becoming too onerous - especially since it needed to be reworked for each new perl release. As for tmux(1) vs screen(1) vs window(1): I don't see any compelling reason for any of these to belong in the base system. (And, if you rely solely on the pkg-descr for those tools, there doesn't appear to be any need for those tools at all unless you are using a real glass TTY on a headless system. Talking to people who use them, it appears that the only useful feature in screen/tmux isn't mentioned in the pkg-descr). -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090923/dd14023f/attachment.pgp From trhodes at FreeBSD.org Thu Sep 24 02:27:18 2009 From: trhodes at FreeBSD.org (Tom Rhodes) Date: Thu Sep 24 02:27:51 2009 Subject: BIND in the base In-Reply-To: <20090923181812.GA14098@rink.nu> References: <200909230906.n8N96KZU004384@lurza.secnetix.de> <4AB9E9F0.3020500@elischer.org> <51C55D74-F18B-4356-811E-13B4AA938D48@80386.nl> <4ABA5965.4090802@elischer.org> <20090923173801.GI95398@hoeg.nl> <20090923181812.GA14098@rink.nu> Message-ID: <20090923221408.5c9af2c1.trhodes@FreeBSD.org> On Wed, 23 Sep 2009 20:18:12 +0200 Rink Springer wrote: > On Wed, Sep 23, 2009 at 07:38:01PM +0200, Ed Schouten wrote: > > I still miss pcvt(4). > > Not a day passes without me missing Alpha.. [*] > > [*] This is not serious, but it should illustrate the point: no one > stepped up, and appearantly no one bothered to try window(1) but > suddenly it's terrible that it was nuked months ago... > > Bottomline: can we PLEASE drop this thread and get to coding? Or in > terms people likely will understand more, 'kill -SIGSTOP $thread'. IIRC, there was a thread on window(1). I'd need to look in my archives to find it, but what I do recall is that only one person stood up and complained AFTER I had removed it. People can put it back if they'd like, and I won't care. :) -- Tom Rhodes From ed at 80386.nl Thu Sep 24 07:14:19 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Sep 24 07:14:25 2009 Subject: BIND in the base In-Reply-To: <20090923221408.5c9af2c1.trhodes@FreeBSD.org> References: <200909230906.n8N96KZU004384@lurza.secnetix.de> <4AB9E9F0.3020500@elischer.org> <51C55D74-F18B-4356-811E-13B4AA938D48@80386.nl> <4ABA5965.4090802@elischer.org> <20090923173801.GI95398@hoeg.nl> <20090923181812.GA14098@rink.nu> <20090923221408.5c9af2c1.trhodes@FreeBSD.org> Message-ID: <20090924071417.GL95398@hoeg.nl> * Tom Rhodes wrote: > People can put it back if they'd like, and I won't care. :) On the condition that does get proper maintenance, unlike previously. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090924/7dba1d26/attachment.pgp From trhodes at FreeBSD.org Thu Sep 24 07:49:57 2009 From: trhodes at FreeBSD.org (Tom Rhodes) Date: Thu Sep 24 07:50:05 2009 Subject: BIND in the base In-Reply-To: <20090924071417.GL95398@hoeg.nl> References: <200909230906.n8N96KZU004384@lurza.secnetix.de> <4AB9E9F0.3020500@elischer.org> <51C55D74-F18B-4356-811E-13B4AA938D48@80386.nl> <4ABA5965.4090802@elischer.org> <20090923173801.GI95398@hoeg.nl> <20090923181812.GA14098@rink.nu> <20090923221408.5c9af2c1.trhodes@FreeBSD.org> <20090924071417.GL95398@hoeg.nl> Message-ID: <20090924034945.69ad9989.trhodes@FreeBSD.org> On Thu, 24 Sep 2009 09:14:17 +0200 Ed Schouten wrote: > * Tom Rhodes wrote: > > People can put it back if they'd like, and I won't care. :) > > On the condition that does get proper maintenance, unlike previously. Actually, that does sound much better, cheers, -- Tom Rhodes From rwatson at FreeBSD.org Sun Sep 27 10:41:22 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Sep 27 10:41:29 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f Message-ID: Dear all-- Those of you at the Cambridge devsummit are already aware of the port of Apple's Grand Central Dispatch (GCD), a.k.a. libdispatch, to FreeBSD by Stacey Son and I, in collaboration with Apple. I've now uploaded my GCD talk slides to the wiki: http://wiki.freebsd.org/200909DevSummit We now have a devel/libdispatch port, which works out-of-the-box on FreeBSD 9-CURRENT. libdispatch requires modest changes to kqueue, which we will merge to 8.x once the code freeze lifts. As of yesterday, I have libdispatch working with Apple's "Blocks" C languae extension as found in clang, the last major architecture component required to use GCD-based applications FreeBSD. Jordan Hubbard at Apple has kindly provided the necessary bits bundled up in a clang/llvm/compiler-rt package for FreeBSD until the clang port is updated. Some details in the attached e-mail. As I mentioned at the FreeBSD developer summit, this is a work-in-progress (in particular, we don't support pthread work queues, which allow the kernel schedule to get involved in expanding the size of the thread worker pool dynamically), but it should now be more than adequate to use in practice. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Sat, 26 Sep 2009 20:37:51 +0100 (BST) From: Robert Watson To: libdispatch-dev@lists.macosforge.org Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on FreeBSD Dear all: This is a quick update for those interested in the general portability of libdispatch, and perhaps specifically FreeBSD. With a bit of help from Jordan Hubbard, I now have libdispatch working with Blocks on FreeBSD. Jordan has put up a FreeBSD clang-devel package that includes Blocks parts and the C runtime bits here: http://static.macosforge.org/libdispatch/downloads/clang-devel.tgz I've updated the libdispatch build parts to detect and use Blocks when compiled with clang, and fixed a few nits in libdispatch that I ran into along the way (and one apparent clang bug). With Jordan's package as a starting point, Blocks pretty much "just worked", so I'm optimistic that people will be able to reproduce this on other platforms able to run the non-Blocks libdispatch without much difficulty. If you update to at least r45 of libdispatch, you should now be able to do: CC=clang ./configure --with-blocks-runtime=/usr/local/lib and get a libdispatch with Blocks support. The reason for the configure argument is that the current clang-devel package doesn't automatically add libBlocksRuntime dependency for binaries compiled with -fblocks. Once Blocks support shakes out a bit more in clang/FreeBSD, this should go away. I am able to run basic Blocks-based test tools with GCD on FreeBSD without difficulty. The FreeBSD port should be updated to reflect this shortly. Robert N M Watson Computer Laboratory University of Cambridge _______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev From bugmaster at FreeBSD.org Mon Sep 28 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 28 11:07:26 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200909281106.n8SB6nqU063921@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From jiashiun at gmail.com Tue Sep 29 17:26:26 2009 From: jiashiun at gmail.com (Jia-Shiun Li) Date: Tue Sep 29 17:26:37 2009 Subject: tmux(1) in base In-Reply-To: <87ocp443e2.fsf@kobe.laptop> References: <20090921112657.GW95398@hoeg.nl> <20090921112917.GA89971@freebsd.org> <20090921113556.GX95398@hoeg.nl> <87ocp443e2.fsf@kobe.laptop> Message-ID: <1d6d20bc0909290958s481f1bbew580baaf3e0e67d7f@mail.gmail.com> On Tue, Sep 22, 2009 at 1:24 AM, Giorgos Keramidas wrote: > ^A is rather comfortable with my Caps Lock key swapped with Ctrl. ?If > the escape character of tmux can be configured to be ^A in the personal > startup configuration of each user, the awkwardness of ^B is really a > very minor issue. > > IMO, a sample screen-like config in /usr/share/examples will go a long > way towards making tmux in the base system a comfortable and viable > screen alternative :) I attempted to write my own .tmux.conf imitating screen key bindings, and then I found it easier to cp /usr/local/share/examples/tmux/screen-keys.conf ~/.tmux.conf ;) Jia-Shiun. From jhb at freebsd.org Wed Sep 30 21:32:22 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 30 21:32:55 2009 Subject: Interrupt Descriptions Message-ID: <200909301732.20589.jhb@freebsd.org> A few folks have asked recently for the ability to add descriptive strings to registered interrupt handlers. This is especially true since the advent of MSI with multiple interrupts per device. I hacked up a prototype today that adds a new 'bus_describe_intr()' that takes the IRQ resource, the void * cookie returned by bus_setup_intr() and var args description and appends that to the interrupt name in the thread and vmstat -i info. The current patch only has the MI bits and the MD bits for amd64 as well as a sample change to the igb(4) driver. The patch is at http://www.FreeBSD.org/~jhb/patches/intr_describe.patch. An example from this patch is: > vmstat -i interrupt total rate irq1: atkbd0 8 0 irq4: uart0 751 5 irq6: fdc0 6 0 irq14: ata0 36 0 irq20: uhci0 20 0 irq23: uhci3 ehci0 2 0 irq28: mpt0 1661 11 irq256: igb0:tx 0 880 6 irq257: igb0:rx 0 1098 7 irq258: igb0:link 3 0 irq259: igb1:tx 0 1 0 irq260: igb1:rx 0 134 0 irq261: igb1:link 3 0 -- John Baldwin From jfvogel at gmail.com Wed Sep 30 23:39:10 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Sep 30 23:39:16 2009 Subject: Interrupt Descriptions In-Reply-To: <200909301732.20589.jhb@freebsd.org> References: <200909301732.20589.jhb@freebsd.org> Message-ID: <2a41acea0909301608o6d0a832fref104ebfbcb0d71f@mail.gmail.com> Good job John, will make my test department very happy :) Once this is in CURRENT I will make changes to the ixgbe driver to use it also. Jack On Wed, Sep 30, 2009 at 2:32 PM, John Baldwin wrote: > A few folks have asked recently for the ability to add descriptive strings > to > registered interrupt handlers. This is especially true since the advent of > MSI with multiple interrupts per device. I hacked up a prototype today > that > adds a new 'bus_describe_intr()' that takes the IRQ resource, the void * > cookie returned by bus_setup_intr() and var args description and appends > that > to the interrupt name in the thread and vmstat -i info. The current patch > only has the MI bits and the MD bits for amd64 as well as a sample change > to > the igb(4) driver. > > The patch is at http://www.FreeBSD.org/~jhb/patches/intr_describe.patch > . > > An example from this patch is: > > > vmstat -i > interrupt total rate > irq1: atkbd0 8 0 > irq4: uart0 751 5 > irq6: fdc0 6 0 > irq14: ata0 36 0 > irq20: uhci0 20 0 > irq23: uhci3 ehci0 2 0 > irq28: mpt0 1661 11 > irq256: igb0:tx 0 880 6 > irq257: igb0:rx 0 1098 7 > irq258: igb0:link 3 0 > irq259: igb1:tx 0 1 0 > irq260: igb1:rx 0 134 0 > irq261: igb1:link 3 0 > > -- > John Baldwin > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >