From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 03:12:24 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90C8416A418; Sun, 13 Jan 2008 03:12:24 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 776DB13C44B; Sun, 13 Jan 2008 03:12:24 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m0D3CJg2069299; Sat, 12 Jan 2008 22:12:21 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 12 Jan 2008 17:14:40 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Robert Watson In-Reply-To: <20080112182948.F36731@fledge.watson.org> Message-ID: <20080112170831.A957@desktop> References: <20071219211025.T899@desktop> <18311.49715.457070.397815@grasshopper.cs.duke.edu> <20080112182948.F36731@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, Andrew Gallatin Subject: Re: Linux compatible setaffinity. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2008 03:12:24 -0000 On Sat, 12 Jan 2008, Robert Watson wrote: > > On Fri, 11 Jan 2008, Andrew Gallatin wrote: > >> I'm somewhat surprised that this has not hit the tree yet. What happened? >> Wasn't the consensus that it was a good thing? > > I think Jeff just got busy with other stuff. > >> FWIW, I was too busy to reply at the time, but I agree that the Apple >> interface is nice. However, sometimes one needs a hard CPU binding >> interface like this one, and I don't see any reason to defer adding this >> interface in favor of the Apple one, since they are somewhat orthogonal. >> I'd be strongly in favor of having a hard CPU binding interface. > > The Apple API is nice in terms of capabilities, but we wouldn't be able to > use it directly as it Mach-esque (as I understand it). Of course, Jeff's > implementation of the Linux API doesn't actually fully implement the API (it > doesn't support constraining the CPU set vs. binding to one CPU, and the > patch as-provided didn't support querying the binding). I agree I'd like to > see if in the tree, if only because it would let me eliminate local hacks I > have that do the same thing, but we should think about other interfaces that > are more expressive in the longer term. > > For example, one thing I like about the Apple interface is the ability to > specify general strategies for affinity rather than specific affinities -- > "these threads like to be together, but they don't mind where that is". > Likewise, the Solaris facility to be able to change a CPU set and have all > the things pinned to it follow the centrally-administered set is a nice match > for our concept of Jail. Finally, if we do want it to work well with Jail, > and we want Jails to be able to be pinned to sets of CPUs, we also need a > nested concept of how to handle affinity, in the event that the set of CPUs a > Jail is running on changes, in which case perhaps you want relative numbering > within the jail, or some other similar notion. > > Sounds like a nice whiteboard session at the BSDCan developer summit... Robert raises some excellent points. I really see three different components here that may not fit within the same api. 1) Binding to a specific cpu or specific set of cpus. This is well handled by the linux api and is necessary under some circumstances. 2) CPU sets and resource management for jails or provisioning. 3) An interface for cache aware applications to hint the scheduler. Sort of like madvise() for cpus. Hopefully most applications would use 3 and 2 would be more of a system level configuration item. The cache aware scheduling would just look at the possible set of cpus for a thread and make some decision about where to put it. There are cerainly a lot of edge cases as robert mentioned. Now, there is one problem with the linux api that I want to discuss before I commit it. The current patch always works on curthread. However, the api allows for setting the binding of a pid. I believe, although I'm not certain, that pids and tids in linux are in the same number space. It's not clear to me whether you can set an affinity for an entire process and have it effect an individual thread or whether you set it on a thread by thread basis. When supplying a non-curproc pid do you bind all threads in the target process? Are our tids and pids in the same number space? And are they available to application programmers? I haven't followed that very carefully. Regardless of what linux does we should figure out what we want to do and hopefully implement that in a way that works with the linuxulator or minimum (hopefully none) application porting effort. Thanks, Jeff > > Robert N M Watson > Computer Laboratory > University of Cambridge > From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 03:44:24 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06E4D16A41A; Sun, 13 Jan 2008 03:44:24 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id CFE6013C461; Sun, 13 Jan 2008 03:44:23 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id m0D3iEfU009779; Sat, 12 Jan 2008 22:44:14 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Sat, 12 Jan 2008 22:44:14 -0500 (EST) Date: Sat, 12 Jan 2008 22:44:14 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Jeff Roberson In-Reply-To: <20080112170831.A957@desktop> Message-ID: References: <20071219211025.T899@desktop> <18311.49715.457070.397815@grasshopper.cs.duke.edu> <20080112182948.F36731@fledge.watson.org> <20080112170831.A957@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Robert Watson , Andrew Gallatin Subject: Re: Linux compatible setaffinity. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2008 03:44:24 -0000 On Sat, 12 Jan 2008, Jeff Roberson wrote: > Now, there is one problem with the linux api that I want to discuss before I > commit it. The current patch always works on curthread. However, the api > allows for setting the binding of a pid. I believe, although I'm not > certain, that pids and tids in linux are in the same number space. It's not > clear to me whether you can set an affinity for an entire process and have it > effect an individual thread or whether you set it on a thread by thread > basis. When supplying a non-curproc pid do you bind all threads in the > target process? > > Are our tids and pids in the same number space? And are they available to > application programmers? I haven't followed that very carefully. I believe marcel made tids and pids disjoint so that any pid is never equal to any tid. But regardless, I don't think we want to rely on that. I would prefer the Solaris approach of specifying what we want (pid, tid, jail id, etc) as an argument in the API so there is no confusion. -- DE From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 05:44:07 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16B9F16A421; Sun, 13 Jan 2008 05:44:07 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id E9D1A13C45D; Sun, 13 Jan 2008 05:44:06 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m0D5i2uh086681; Sun, 13 Jan 2008 00:44:03 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 12 Jan 2008 19:46:23 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Daniel Eischen In-Reply-To: Message-ID: <20080112194521.I957@desktop> References: <20071219211025.T899@desktop> <18311.49715.457070.397815@grasshopper.cs.duke.edu> <20080112182948.F36731@fledge.watson.org> <20080112170831.A957@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Robert Watson , Andrew Gallatin Subject: Re: Linux compatible setaffinity. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2008 05:44:07 -0000 On Sat, 12 Jan 2008, Daniel Eischen wrote: > On Sat, 12 Jan 2008, Jeff Roberson wrote: > >> Now, there is one problem with the linux api that I want to discuss before >> I commit it. The current patch always works on curthread. However, the >> api allows for setting the binding of a pid. I believe, although I'm not >> certain, that pids and tids in linux are in the same number space. It's >> not clear to me whether you can set an affinity for an entire process and >> have it effect an individual thread or whether you set it on a thread by >> thread basis. When supplying a non-curproc pid do you bind all threads in >> the target process? >> >> Are our tids and pids in the same number space? And are they available to >> application programmers? I haven't followed that very carefully. > > I believe marcel made tids and pids disjoint so that any pid is > never equal to any tid. But regardless, I don't think we want > to rely on that. I would prefer the Solaris approach of specifying > what we want (pid, tid, jail id, etc) as an argument in the API > so there is no confusion. Yes, I would prefer that as well I believe. So I'll add an extra parameter and in the linux code we'll use whatever their default is. Of course the initial implementation will still only support curthread but I plan on finishing the rest before 8.0 is done. Jeff > > -- > DE > From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 11:17:28 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98AAE16A417 for ; Mon, 14 Jan 2008 11:17:28 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 74BB313C448 for ; Mon, 14 Jan 2008 11:17:27 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 205EA74400E for ; Mon, 14 Jan 2008 12:52:23 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+cJABb-87fk for ; Mon, 14 Jan 2008 12:52:23 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id D429574400C for ; Mon, 14 Jan 2008 12:52:22 +0200 (EET) Message-ID: <478B3EE0.8040908@icyb.net.ua> Date: Mon, 14 Jan 2008 12:52:16 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: cdcontrol purpose X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 11:17:28 -0000 The following question may seem to be offtopic for this list, but I think that it's not because it is related not only to cdcontrol utility itself but also to the CD-ROM drivers. The question: should cdcontrol utility be able to eject a mounted disk (i.e. a filesystem on the disk is mounted) ? This question could also be understood as: should cdcontrol be a powerful administration tool that allows foot-shooting or should it be a basic tool that gives a user some control over a CD-ROM drive ? cdcontrol(1) seems to hint at the latter: DESCRIPTION The cdcontrol utility is a program to control audio features of a CD drive. The device is a name such as cd0 or acd0. [emphasis on "audio features"] More technical background description can be found at: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=457200+0+archive/2007/freebsd-stable/20071223.freebsd-stable Description of even weirder problems caused by smart userland software (HAL), dozen message thread: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=785719+0+archive/2007/freebsd-questions/20071216.freebsd-questions P.S. CVS log suggests that cdcontrol code stayed the same from initial version 1.1. P.P.S. issuing ioctl(CDIOCALLOW) before closing tray seems even more dubious. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 15:07:27 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A8AF16A420 for ; Mon, 14 Jan 2008 15:07:27 +0000 (UTC) (envelope-from raffaele.delorenzo@libero.it) Received: from grupposervizi.it (mail1.tagetik.com [85.18.71.243]) by mx1.freebsd.org (Postfix) with SMTP id 6E95413C478 for ; Mon, 14 Jan 2008 15:07:25 +0000 (UTC) (envelope-from raffaele.delorenzo@libero.it) Received: (qmail 9225 invoked by uid 453); 14 Jan 2008 15:07:24 -0000 Received: from [192.9.217.29] (HELO noel.grupposervizi.it) (192.9.217.29) by grupposervizi.it (qpsmtpd/0.31.1) with ESMTP; Mon, 14 Jan 2008 16:07:24 +0100 Message-ID: <478B7AA6.9010304@libero.it> Date: Mon, 14 Jan 2008 16:07:18 +0100 From: Raffaele De Lorenzo User-Agent: Thunderbird 2.0.0.9 (X11/20071204) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, freebsd-security@freebsd.org, freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "raffaele.delorenzo" Subject: Added native socks support to libc in FreeBSD 7 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 15:07:27 -0000 Upgrade: 1) Added IPv6 Support (need to be tested) Cheers Raffaele Hi, i added a native (client) Socks V4/V5 support inside FreeBSD libc library. The work is based of my project (see http://csocks.altervista.org) CSOCKS. You can get it here: http://csocks.altervista.org/download/FreeBSD_libc.tar.gz CHANGES: I changed the file: /usr/src/lib/libc/Makefile I added the Directory: /usr/src/lib/libc/socks They contains the files: csocks.c csocks.h csocks.conf.5 csocks.1 Makefile.inc I added the configuration file (csocks.conf in the /etc/ directory) /usr/src/etc/ INSTALL ISTRUCTIONS: copy the Makefile in /usr/src/lib/libc/ copy the directory socks in /usr/src/lib/libc/ touch /etc/csocks.conf recompile the libc and install it (cd /usr/src/lib/libc && make && make install) I Tested it in FreeBSD 7 only on i386 cheers Raffaele From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 15:12:44 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B693116A417 for ; Mon, 14 Jan 2008 15:12:44 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id 93B0B13C45B for ; Mon, 14 Jan 2008 15:12:44 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.mx.meer.net (8.12.10/8.12.6) with ESMTP id m0EFCi7T055312; Mon, 14 Jan 2008 07:12:44 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m0EFChxf034596; Mon, 14 Jan 2008 07:12:43 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from gnnbsd.hudson-trading.com.neville-neil.com ([66.150.84.1]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m0EFCgVu032282; Mon, 14 Jan 2008 07:12:43 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Mon, 14 Jan 2008 10:12:42 -0500 Message-ID: <7iir1wtp91.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: Andriy Gapon In-Reply-To: <478B3EE0.8040908@icyb.net.ua> References: <478B3EE0.8040908@icyb.net.ua> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/21.3 (amd64--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-arch@freebsd.org Subject: Re: cdcontrol purpose X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 15:12:44 -0000 At Mon, 14 Jan 2008 12:52:16 +0200, Andriy Gapon wrote: > > > The following question may seem to be offtopic for this list, but I > think that it's not because it is related not only to cdcontrol utility > itself but also to the CD-ROM drivers. > > The question: should cdcontrol utility be able to eject a mounted disk > (i.e. a filesystem on the disk is mounted) ? > I come down on the side of "separation of concerns" and think that mount should deal with filesystems and that cdcontrol should not. Best, George From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 16:09:30 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0475E16A47B for ; Mon, 14 Jan 2008 16:09:30 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id CAE3513C45B for ; Mon, 14 Jan 2008 16:09:29 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 3986C1A4D80; Mon, 14 Jan 2008 08:06:17 -0800 (PST) Date: Mon, 14 Jan 2008 08:06:17 -0800 From: Alfred Perlstein To: gnn@freebsd.org Message-ID: <20080114160617.GN99258@elvis.mu.org> References: <478B3EE0.8040908@icyb.net.ua> <7iir1wtp91.wl%gnn@neville-neil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7iir1wtp91.wl%gnn@neville-neil.com> User-Agent: Mutt/1.4.2.3i Cc: Andriy Gapon , freebsd-arch@freebsd.org Subject: Re: cdcontrol purpose X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 16:09:30 -0000 * gnn@freebsd.org [080114 07:11] wrote: > At Mon, 14 Jan 2008 12:52:16 +0200, > Andriy Gapon wrote: > > > > > > The following question may seem to be offtopic for this list, but I > > think that it's not because it is related not only to cdcontrol utility > > itself but also to the CD-ROM drivers. > > > > The question: should cdcontrol utility be able to eject a mounted disk > > (i.e. a filesystem on the disk is mounted) ? > > > > I come down on the side of "separation of concerns" and think that > mount should deal with filesystems and that cdcontrol should not. I agree. I can't tell if Andriy is suggesting that cdcontrol unmount the filesystem forcefully or at least attempt to unmount it. I would say that it might make sense for cdcontrol to grow a flag to "unmount non-forcefully if mounted", but certainly not to unmount by default. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 17:00:56 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6641416A41B; Mon, 14 Jan 2008 17:00:56 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 791DD13C455; Mon, 14 Jan 2008 17:00:50 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id ED7AB744005; Mon, 14 Jan 2008 19:00:48 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtEGSZg7v83S; Mon, 14 Jan 2008 19:00:48 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 8351D744002; Mon, 14 Jan 2008 19:00:48 +0200 (EET) Message-ID: <478B953F.1070209@icyb.net.ua> Date: Mon, 14 Jan 2008 19:00:47 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: Alfred Perlstein References: <478B3EE0.8040908@icyb.net.ua> <7iir1wtp91.wl%gnn@neville-neil.com> <20080114160617.GN99258@elvis.mu.org> In-Reply-To: <20080114160617.GN99258@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: gnn@freebsd.org, freebsd-arch@freebsd.org Subject: Re: cdcontrol purpose X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 17:00:56 -0000 on 14/01/2008 18:06 Alfred Perlstein said the following: > * gnn@freebsd.org [080114 07:11] wrote: >> At Mon, 14 Jan 2008 12:52:16 +0200, >> Andriy Gapon wrote: >>> >>> The following question may seem to be offtopic for this list, but I >>> think that it's not because it is related not only to cdcontrol utility >>> itself but also to the CD-ROM drivers. >>> >>> The question: should cdcontrol utility be able to eject a mounted disk >>> (i.e. a filesystem on the disk is mounted) ? >>> >> I come down on the side of "separation of concerns" and think that >> mount should deal with filesystems and that cdcontrol should not. This is how it is. The philosophical question is: if mount is able to prevent physical media of the fs from disappearing, should it employ that capability ? Currently, it does. > I agree. > > I can't tell if Andriy is suggesting that cdcontrol unmount the filesystem > forcefully or at least attempt to unmount it. > > I would say that it might make sense for cdcontrol to grow a flag > to "unmount non-forcefully if mounted", but certainly not to > unmount by default. > Well, I never suggested (or even had a thought) that cdcontrol should get into (un)mounting business, or even doing any checks. It is a simple tool and should stay simple. It boils down to the following: when you do mount a filesystem on CD/DVD (or otherwise open(2) cd/acd device) CD-ROM driver issues a command to lock a tray ("prevent"). I think that this is very reasonable as it prevents a user from accidentally ejecting (using a physical button, that is) and even replacing a disk while something has it in use. So I hope my question would be clearer now: should cdcontrol be allowed to override "prevent" issued by mount/open(2) and eject a disk in use ? Or should it simply fail in the same way that the physical button is disabled? -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 17:09:37 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D04616A46B; Mon, 14 Jan 2008 17:09:37 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0E7F913C4CC; Mon, 14 Jan 2008 17:09:36 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 4D4701A4D7E; Mon, 14 Jan 2008 09:06:24 -0800 (PST) Date: Mon, 14 Jan 2008 09:06:24 -0800 From: Alfred Perlstein To: Andriy Gapon Message-ID: <20080114170624.GR99258@elvis.mu.org> References: <478B3EE0.8040908@icyb.net.ua> <7iir1wtp91.wl%gnn@neville-neil.com> <20080114160617.GN99258@elvis.mu.org> <478B953F.1070209@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <478B953F.1070209@icyb.net.ua> User-Agent: Mutt/1.4.2.3i Cc: gnn@freebsd.org, freebsd-arch@freebsd.org Subject: Re: cdcontrol purpose X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 17:09:37 -0000 * Andriy Gapon [080114 08:57] wrote: > So I hope my question would be clearer now: should cdcontrol be allowed > to override "prevent" issued by mount/open(2) and eject a disk in use ? > Or should it simply fail in the same way that the physical button is > disabled? It should not. If in that situation the tool does not emit a diagnostic that's useful then it could be augmented to do so. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 17:21:55 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68B5D16A418; Mon, 14 Jan 2008 17:21:55 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id E3DB413C465; Mon, 14 Jan 2008 17:21:54 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 126FC744011; Mon, 14 Jan 2008 19:21:51 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLOojjhCLWEJ; Mon, 14 Jan 2008 19:21:50 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3A3C2744008; Mon, 14 Jan 2008 19:21:50 +0200 (EET) Message-ID: <478B9A2C.4080206@icyb.net.ua> Date: Mon, 14 Jan 2008 19:21:48 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: Alfred Perlstein References: <478B3EE0.8040908@icyb.net.ua> <7iir1wtp91.wl%gnn@neville-neil.com> <20080114160617.GN99258@elvis.mu.org> <478B953F.1070209@icyb.net.ua> <20080114170624.GR99258@elvis.mu.org> In-Reply-To: <20080114170624.GR99258@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: gnn@freebsd.org, freebsd-arch@freebsd.org Subject: Re: cdcontrol purpose X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 17:21:55 -0000 on 14/01/2008 19:06 Alfred Perlstein said the following: > * Andriy Gapon [080114 08:57] wrote: >> So I hope my question would be clearer now: should cdcontrol be allowed >> to override "prevent" issued by mount/open(2) and eject a disk in use ? >> Or should it simply fail in the same way that the physical button is >> disabled? > > It should not. Sorry, I am not completely sure which question you answered with that, damn alternative questions :-) > If in that situation the tool does not emit a diagnostic that's > useful then it could be augmented to do so. > -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 21:37:01 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A5C616A417; Mon, 14 Jan 2008 21:37:01 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2017C13C448; Mon, 14 Jan 2008 21:37:00 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 363971A4D7E; Mon, 14 Jan 2008 13:33:47 -0800 (PST) Date: Mon, 14 Jan 2008 13:33:47 -0800 From: Alfred Perlstein To: Andriy Gapon Message-ID: <20080114213347.GU99258@elvis.mu.org> References: <478B3EE0.8040908@icyb.net.ua> <7iir1wtp91.wl%gnn@neville-neil.com> <20080114160617.GN99258@elvis.mu.org> <478B953F.1070209@icyb.net.ua> <20080114170624.GR99258@elvis.mu.org> <478B9A2C.4080206@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <478B9A2C.4080206@icyb.net.ua> User-Agent: Mutt/1.4.2.3i Cc: gnn@freebsd.org, freebsd-arch@freebsd.org Subject: Re: cdcontrol purpose X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 21:37:01 -0000 * Andriy Gapon [080114 09:18] wrote: > on 14/01/2008 19:06 Alfred Perlstein said the following: > > * Andriy Gapon [080114 08:57] wrote: > >> So I hope my question would be clearer now: should cdcontrol be allowed > >> to override "prevent" issued by mount/open(2) and eject a disk in use ? > >> Or should it simply fail in the same way that the physical button is > >> disabled? > > > > It should not. > > Sorry, I am not completely sure which question you answered with that, > damn alternative questions :-) > Regarding: > >> should cdcontrol be allowed > >> to override "prevent" issued by mount/open(2) and eject a disk in use ? It should not do this. It should NOT eject a disk in use. Furthermore: > > If in that situation the tool does not emit a diagnostic that's > > useful then it could be augmented to do so. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 21:40:49 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0328016A41B; Mon, 14 Jan 2008 21:40:49 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1165313C465; Mon, 14 Jan 2008 21:40:46 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <478BD6DE.1070407@FreeBSD.org> Date: Mon, 14 Jan 2008 22:40:46 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alfred Perlstein References: <478B3EE0.8040908@icyb.net.ua> <7iir1wtp91.wl%gnn@neville-neil.com> <20080114160617.GN99258@elvis.mu.org> <478B953F.1070209@icyb.net.ua> <20080114170624.GR99258@elvis.mu.org> <478B9A2C.4080206@icyb.net.ua> <20080114213347.GU99258@elvis.mu.org> In-Reply-To: <20080114213347.GU99258@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gnn@freebsd.org, Andriy Gapon , freebsd-arch@freebsd.org Subject: Re: cdcontrol purpose X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 21:40:49 -0000 Alfred Perlstein wrote: > * Andriy Gapon [080114 09:18] wrote: >> on 14/01/2008 19:06 Alfred Perlstein said the following: >>> * Andriy Gapon [080114 08:57] wrote: >>>> So I hope my question would be clearer now: should cdcontrol be allowed >>>> to override "prevent" issued by mount/open(2) and eject a disk in use ? >>>> Or should it simply fail in the same way that the physical button is >>>> disabled? >>> It should not. >> Sorry, I am not completely sure which question you answered with that, >> damn alternative questions :-) >> > > Regarding: > >>>> should cdcontrol be allowed >>>> to override "prevent" issued by mount/open(2) and eject a disk in use ? > > It should not do this. It should NOT eject a disk in use. > > Furthermore: > >>> If in that situation the tool does not emit a diagnostic that's >>> useful then it could be augmented to do so. > > > When I tried this last it indeed did not eject a mounted CDROM. I wonder if Andriy's hardware is not responding to the "lock media" command or something. Can anyone else confirm this behaviour? Kris From owner-freebsd-arch@FreeBSD.ORG Tue Jan 15 02:37:30 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5139F16A421; Tue, 15 Jan 2008 02:37:30 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id 247A813C4D5; Tue, 15 Jan 2008 02:37:30 +0000 (UTC) (envelope-from rrs@cisco.com) X-IronPort-AV: E=Sophos;i="4.24,284,1196668800"; d="scan'208";a="8107465" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 14 Jan 2008 18:37:29 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0F2bTaH028033; Mon, 14 Jan 2008 18:37:29 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0F2bPid015263; Tue, 15 Jan 2008 02:37:29 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 18:35:17 -0800 Received: from [128.107.155.117] ([128.107.155.117]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 18:35:17 -0800 Message-ID: <478C1B4D.4070507@cisco.com> Date: Mon, 14 Jan 2008 21:32:45 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qing Li References: <30834.1199989743@speakeasy.net> <4788F1AE.4030502@cisco.com> <001801c85555$8d3bd970$8d335140@SAINTS> In-Reply-To: <001801c85555$8d3bd970$8d335140@SAINTS> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2008 02:35:17.0165 (UTC) FILETIME=[43B5CDD0:01C8571F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8979; t=1200364649; x=1201228649; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Routing=20in=20the=20network=20=3A-) |Sender:=20; bh=KFOqP+jfVkIyGRVo68IEBw8ePExte+VojwbAqfifrM8=; b=VVx8ekhu0xb5/qz/rUiAWNa4hvA1wMQmhmD9ayN/o/BXC0u9tomm3ypnja De370cJOQFhpf8SVrmv2l3wmJbBBxic17FnUpJyipT9uQVDIHfItw2edCUPg fLYanX0Vmg; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: qingli@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Routing in the network :-) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2008 02:37:30 -0000 Great.. I will await your email :-D R Qing Li wrote: > Okay, I will pull the branch and start the work on it. > Let me get all of my changes in place and after testing > the features out, I will ping you and you can let me > know if you require additional support, we'll just go > from there. > > -- Qing > > > >>-----Original Message----- >>From: owner-freebsd-arch@freebsd.org >>[mailto:owner-freebsd-arch@freebsd.org] On Behalf Of Randall Stewart >>Sent: Saturday, January 12, 2008 8:58 AM >>To: qingli@speakeasy.net >>Cc: qingli@freebsd.org; freebsd-arch@freebsd.org >>Subject: Re: Routing in the network :-) >> >>Qing Li: >> >>Ok, the branch is created :-) >> >>//depot/user/rrs/alt_route >> >>Please go ahead and pull a copy and add your changes.. unless >>you would like me to ressurect my old patches.. (let me know).. >> >>If you put your patches in ping me to tell me they are in .. >>and then I will ressurect my old alternate route lookup patch >>and the changes to SCTP to use it :-) >> >>Ping me either way >> >> >>R >> >>Qing Li wrote: >> >>> Interesting you are bringing this up ... I actually >> >>sent a similar email to freebsd-net@ >> >>> about 2 years ago and had one response back (it was a >> >>polite no). >> >>> I back ported and integrated the radix_mpath changes >> >>from KAME into FreeBSD 5.4 >> >>> and the changes are working good right now in >> >>production environment. Changes >> >>> were also necessary in quite a few place throughout the >> >>netinet/ files, e.g., >> >>> address initialization functions such as in_ifinit(). >>> >>> I actually discussed what I have done with itojun back >> >>in August of 2007. >> >>> >>>>On Thu Jan 10 6:55 , Randall Stewart sent: >>>> >>>>Hi all: >>>> >>>>A number of years ago, Itojun and I had played off and on with some >>>>modifications to both the routing table and to a "new" >> >>interfaces that >> >>>>could be used by transports to gain routing information. >>>> >>>>I am contemplating digging back in my archives and building a p4 >>>>branch that would have the changes for folks to look at.. >>>>But before I go to all that trouble I want to have a >> >>discussion about >> >>>>this here ;-) >>>> >>>>This will be a longish email so if you get bored easily or >> >>just don't >> >>>>care about routing/networks and all that fun, you have been >> >>warned :-) >> >>>>The basic concept: >>>> >>>>So say I am at home and have purchased two DSL's. One from >> >>AT&T (don't >> >>>>you love the new ma-bell) and the other from SpeakEasy (Note I had >>>>this until I moved out to the country now I am lucky to >> >>have one DSL.. >> >>>>but many can do this if they want)... So my home looked like: >>>> >>>> >>>>IP-A IP-S >>>>| | >>>>| | >>>>| | >>>>,__|__________|___ >>>>| | >>>>| | >>>>| lakerest.net | >>>>| | >>>>|_________________| >>>> >>>>Now life is good, I have some degree of fault tolerance right? >>>> >>>>So AT&T (IP-A) gives me the default route to IP-A1 and Speak Easy >>>>gives me the default route to IP-S1. >>>>Life is not so good... how do I plumb these in the routing table? >>>> >>>>I can say >>>> >>>>route add default IP-A1 >>>>or >>>>route add default IP-S1 >>>> >>>>But I cannot have both. And worse if I had a connection up to >>>>FreeBSD.net and AT&T's network went down.. and I happened >> >>to have put >> >>>>the first command in.. my network connection would stop... >>>> >>>>What would be nice if I had a way to add BOTH routes into >> >>the kernel.. >> >>>>and when Layer 4 realized there was some major problems going on it >>>>could "use" the alternate route (i.e. via IP-S1) and life >> >>would once >> >>>>again be good.. >>>> >>>>Ok, yes, the observant person out there will say.. wait >>>>IP-S1 will NEVER allow your packets through since they probably do >>>>ingress filtering.. yes I am aware of this.. but this would >> >>*NOT* hold >> >>>>true for some device in the network talking to some other device in >>>>the network.. *OR* for speakeasy.. at least not circa 2004.. since >>>>speakeasy did *NOT* do ingress filtering and my way back former >>>>employer (AT&T) *DID* do ingress filtering.. >>>> >>>>So the idea is rather simple: >>>> >>>>1) Allow multiple routes on any level of the kernel patricia trees. >>>> >>> >>> >>> This is done. >>> >>> >>> >>>>2) Add an additional interface to the routing code so that >> >>a transport >> >>>>protocol could query the routing table for additional >> >>support... i.e. >> >>>>excuse me, the route that I had no longer seems to be >> >>working, do you >> >>>>have an alternate gateway? >>>> >>> >>> >>> There was a inp_route field in the in_pcb{} structure but >>> that field was later removed by Andre in 5.5. I never quite >>> understood why but I did find that field to be rather useful. >>> >>> union { >>> /* placeholder for routing entry */ >>> struct route inc4_route; >>>#if 1 /* def NEW_STRUCT_ROUTE */ >>> struct route inc6_route; >>>#else >>> struct route_in6 inc6_route; >>>#endif >>> } inc_dependroute; >>> >>> I used this field for caching and it gets flushed when >>> there is a routing table change. Works out good. >>> >>> >>> >>>>Now I admit for TCP these API's would have limited use.. >>>> >>> >>> >>> That depends ... :-) >>> >>> >>> >>>>but for SCTP these are golden.. since both sides know about all >>>>addresses and thus you get a form of true network diversity out of >>>>this little software change. >>>> >>>> >>>>Now yes, this does not help you if both your DSL's go out >> >>to the same >> >>>>pole outside your house, and a truck hits the pole... but it *DOES* >>>>help you if your network provider dies somewhere back in the CO >>>>running across your carpet to AT&T's DSL and it thinks >> >>chewing on it >> >>>>would be fun :-) >>>> >>>>So what was required way back in 4.x when Itojun and I did >> >>this work.. >> >>>>(note that Itojun called his changes RADIX_MPATH which did >> >>NOT include >> >>>>my alternate routing lookup code). >>>> >>>>a) For radix.c there were just a few simple changes that >> >>removed the >> >>>>restriction that prevents duplicate routes at any level of the tree. >>>> >>>>b) For route.c a new method is added.. this is a bit of >> >>code not huge >> >>>>but some. >>>> >>> >>> >>> The rtrequest1() function needed a bit of work but not so huge. >>> >>> >>> >>>>c) One thing I added but took back out, was some changes to >> >>the "route >> >>>>delete" api... can't remember exactly where.. but basically >> >>the delete >> >>>>does not look at the destination ... i.e. >>>>with the changes Itojun and I had cooked up if you said: >>>>route add default IP-1 >>>>route add default IP-2 >>>>route add default IP-3 >>>> >>>>and then when.. opps.. I don't want IP-2, you could NOT say route >>>>delete default IP-2.. well you could but it did no good.. >> >>it removed >> >>>>the first one (IP-1). I had a fix for this but Itojun >> >>thought it was >> >>>>too radical since it changed an interface to one of the routing >>>>routines... so we just settled for the fact that if you did >> >>that you >> >>>>got to have the pleasure of using: >>>>route delete default >>>>3 times.. and then starting again... >>>> >>> >>> >>> I have been enhancing the code for some time now ... >>> >>> I can do both route delete and even route modification (I added >>> route preferences in addition to ECMP). >>> >>> I have 7 fundamental test cases to perform on the >> >>implementation to ensure >> >>> both correctness and compatibility. >>> >>> >>> >>>>So is it worth my time resurrecting these patches for 8.0? >> >>Objections >> >>>>(being in a routing company I know there will be a lot of them.. >>>>gee the routing system is supposed to do that.. etc etc). >>>> >>>>Comments would be welcome before I dust off the patches.. >>>> >>> >>> >>> I would like to get these changes made into 8.0. >>> >>> If there is enough interest out there, I'd be happy to >> >>share my implementation >> >>> and we probabaly can collaborate on this effort if that >> >>works for you. >> >>> -- Qing >>> >>> >>> >>>R >> >> >>-- >>Randall Stewart >>NSSTG - Cisco Systems Inc. >>803-345-0369 803-317-4952 (cell) >>_______________________________________________ >>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" >> >> > > > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-arch@FreeBSD.ORG Tue Jan 15 09:29:50 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F3F716A418; Tue, 15 Jan 2008 09:29:50 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 97D5A13C457; Tue, 15 Jan 2008 09:29:49 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id B7DEA43C03A; Tue, 15 Jan 2008 11:29:47 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B31Jv8WjXobZ; Tue, 15 Jan 2008 11:29:47 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id E685743C031; Tue, 15 Jan 2008 11:29:46 +0200 (EET) Message-ID: <478C7D09.5050402@icyb.net.ua> Date: Tue, 15 Jan 2008 11:29:45 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: Kris Kennaway References: <478B3EE0.8040908@icyb.net.ua> <7iir1wtp91.wl%gnn@neville-neil.com> <20080114160617.GN99258@elvis.mu.org> <478B953F.1070209@icyb.net.ua> <20080114170624.GR99258@elvis.mu.org> <478B9A2C.4080206@icyb.net.ua> <20080114213347.GU99258@elvis.mu.org> <478BD6DE.1070407@FreeBSD.org> In-Reply-To: <478BD6DE.1070407@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: gnn@FreeBSD.org, Alfred Perlstein , freebsd-arch@FreeBSD.org Subject: Re: cdcontrol purpose X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2008 09:29:50 -0000 on 14/01/2008 23:40 Kris Kennaway said the following: > Alfred Perlstein wrote: >> * Andriy Gapon [080114 09:18] wrote: >>> on 14/01/2008 19:06 Alfred Perlstein said the following: >>>> * Andriy Gapon [080114 08:57] wrote: >>>>> So I hope my question would be clearer now: should cdcontrol be allowed >>>>> to override "prevent" issued by mount/open(2) and eject a disk in use ? >>>>> Or should it simply fail in the same way that the physical button is >>>>> disabled? >>>> It should not. >>> Sorry, I am not completely sure which question you answered with that, >>> damn alternative questions :-) >>> >> Regarding: >> >>>>> should cdcontrol be allowed >>>>> to override "prevent" issued by mount/open(2) and eject a disk in use ? >> It should not do this. It should NOT eject a disk in use. >> >> Furthermore: >> >>>> If in that situation the tool does not emit a diagnostic that's >>>> useful then it could be augmented to do so. >> >> > > When I tried this last it indeed did not eject a mounted CDROM. I > wonder if Andriy's hardware is not responding to the "lock media" > command or something. Can anyone else confirm this behaviour? Kris, as I reported in this posting: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=457200+0+archive/2007/freebsd-stable/20071223.freebsd-stable the behavior differs for SCSI and ATAPI devices, with the latter some checks within the driver forbid 'eject' command, but do not forbid 'allow'. So, while you can not eject a disk with cdcontrol alone, drive's tray becomes unlocked and now you can do it with a physical button. This is even weirder behavior than what happens with SCSI. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Tue Jan 15 20:16:31 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D65216A417 for ; Tue, 15 Jan 2008 20:16:31 +0000 (UTC) (envelope-from u25192@vm39.bln2.vrmd.de) Received: from vm39.bln2.vrmd.de (vm39.bln2.vrmd.de [81.28.232.70]) by mx1.freebsd.org (Postfix) with ESMTP id D357D13C45A for ; Tue, 15 Jan 2008 20:16:30 +0000 (UTC) (envelope-from u25192@vm39.bln2.vrmd.de) Received: from u25192 by vm39.bln2.vrmd.de with local (Exim 4.60) (envelope-from ) id 1JErrO-0000v7-HI for freebsd-arch@freebsd.org; Tue, 15 Jan 2008 20:54:10 +0100 To: freebsd-arch@freebsd.org From: Citibank Australia Content-Transfer-Encoding: 8bit Message-Id: Date: Tue, 15 Jan 2008 20:54:10 +0100 MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: your profile has been locked X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: profiles@citibank.com.au List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2008 20:16:31 -0000 Your Online Banking Profile Has Been Blocked For your security, your online banking profile has been locked due to inactivity or because of many failed login attempts. [1] Click Here to re-activate your Citibank account © 1999 2008 Citibank Australia. All rights reserved. References 1. http://www.fqmurcia.org//portal/themes/aston_flower_red/images/citibank.com.au/www.citibank.com.au/ From owner-freebsd-arch@FreeBSD.ORG Wed Jan 16 02:07:01 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07DAA16A41B for ; Wed, 16 Jan 2008 02:07:01 +0000 (UTC) (envelope-from SRS0=VVro=SG=claro.com.br=mensagem@srs.kundenserver.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id 7EF2F13C474 for ; Wed, 16 Jan 2008 02:07:00 +0000 (UTC) (envelope-from SRS0=VVro=SG=claro.com.br=mensagem@srs.kundenserver.de) Received: from infong387.kundenserver.de (infong387.kundenserver.de [212.227.127.182]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1JExU22My8-0000P5; Wed, 16 Jan 2008 02:54:26 +0100 Received: from 201.86.240.124 (IP may be forged by CGI script) by infong387.kundenserver.de with HTTP id 4AgGcx-1JExU224WH-00010D; Wed, 16 Jan 2008 02:54:26 +0100 X-Sender-Info: <150899874@infong387.kundenserver.de> Date: Wed, 16 Jan 2008 02:54:26 +0100 Message-Id: <4AgGcx-1JExU224WH-00010D@infong387.kundenserver.de> Precedence: bulk To: freebsd-arch@FreeBSD.org From: X-Provags-ID: V01U2FsdGVkX184Pr8wZkq9d74wlym0huk4YX/InpR7hSJuJlt 5f/ppvmKQk+PXE3AjiZKSqUhkCBT0fnV+dmIeHYc+THqVFXM5w a6lW1MWdaNFdL7TeOcMTA== MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Que 2008 seja de paz e harmonia ( me liga felicidades) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2008 02:07:01 -0000 Que 2008 seja de paz e harmonia ( me liga felicidades) [tit_grupo_video_download.gif] [logo_claro.jpg] Voc recebeu um Claro Vdeo Download! Claro Vdeo Download enviado do nmero 0XX 92645433 [1]Visualizar Claro Vdeo Download (90kb / tempo estimado: 0:50seg) Importante: Claro Vdeo Download ficar disponvel na Web durante 7 dias. Claro. A vida na sua mo. [2]Site da Claro | [3]Termos de uso | [4]Poltica de Privacidade Copyright Claro 2006 References 1. http://216.133.246.52/clarovideomensagem/video.scr 2. http://www.claroideias.com.br/portal/site/CIdeias/menuitem.7df34df2cc1d8a7933d1593b22dc10a0/&idlocal=56 3. http://www.claroideias.com.br/portal/site/CIdeias/menuitem.7df34df2cc1d8a7933d1593b22dc10a0/&idlocal=56 4. http://www.claroideias.com.br/portal/site/CIdeias/menuitem.7df34df2cc1d8a7933d1593b22dc10a0/&idlocal=56 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 17 06:30:16 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5836716A417; Thu, 17 Jan 2008 06:30:16 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id C3F7513C45B; Thu, 17 Jan 2008 06:30:15 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mx-av-01.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id m0H4Rveu018397; Thu, 17 Jan 2008 06:27:57 +0200 Received: from MX-IN-03.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.32]) by mx-av-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id m0H4RvEg027531; Thu, 17 Jan 2008 06:27:57 +0200 Received: from kobe.laptop (ppp176-5.adsl.forthnet.gr [62.1.179.5]) by MX-IN-03.forthnet.gr (8.14.2/8.14.2) with ESMTP id m0H4RotA002829; Thu, 17 Jan 2008 06:27:51 +0200 Authentication-Results: MX-IN-03.forthnet.gr smtp.mail=keramida@freebsd.org; spf=permerror Authentication-Results: MX-IN-03.forthnet.gr header.from=keramida@freebsd.org; sender-id=permerror Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m0H4Rn4M001708; Thu, 17 Jan 2008 06:27:49 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m0H4RmfM001707; Thu, 17 Jan 2008 06:27:48 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Thu, 17 Jan 2008 06:27:48 +0200 From: Giorgos Keramidas To: Andre Oppermann Message-ID: <20080117042747.GA1617@kobe.laptop> References: <20071219123305.Y95322@fledge.watson.org> <47693DBD.6050104@swin.edu.au> <476A45D6.6030305@freebsd.org> <47858D35.6060006@swin.edu.au> <4786D23A.1080509@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4786D23A.1080509@freebsd.org> Cc: James Healy , Lawrence Stewart , net@freebsd.org, Robert Watson , arch@freebsd.org Subject: Re: Coordinating TCP projects X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2008 06:30:16 -0000 On 2008-01-11 03:19, Andre Oppermann wrote: >Lawrence Stewart wrote: >>> I've got a rewritten and much more efficient tcp_reass() function in >>> my local tree. I'll import it into Perforce next week with all the >>> other stuff. You may want to base your auto-sizing work on it. The >>> only missing parts are some statistics gathering. >> >> Where abouts is this code? A cursory browse through the Perforce web >> front-end reveals nothing. We're going to start work on the TCP >> reassembly queue autotuning patch now and if you think we should base >> it on your new tcp_reass() we need to have a look at it. > > The first cut is now at //depot/projects/tcp_reass/ however I made a > mistake when creating the branch and now the code is in the same > changeset as the branching itself. Doesn't make it easy to do a diff. > Have to see how I can fix that. Anyway, have a look and I'm going to > finish/fix the code tomorrow evening. Hi Andre, You can `p4 obliterate' the branch and recommit. Alternatively, you can commit a second change, with the clean branch-origin source, and then re-commit the tcp_reass code. The perforce-admins may have a preferred way of fixing this, so it's probably worth asking too. HTH, Giorgos From owner-freebsd-arch@FreeBSD.ORG Thu Jan 17 22:31:21 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8BD516A418 for ; Thu, 17 Jan 2008 22:31:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 9CAFF13C457 for ; Thu, 17 Jan 2008 22:31:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 228881272-1834499 for ; Thu, 17 Jan 2008 17:29:28 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m0HMVDCs085244 for ; Thu, 17 Jan 2008 17:31:13 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: arch@freebsd.org Date: Thu, 17 Jan 2008 17:31:09 -0500 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801171731.09873.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 17 Jan 2008 17:31:13 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5493/Thu Jan 17 13:09:26 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Simple framework for regression tests in src/tools/regression X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2008 22:31:21 -0000 When I converted the test program for the posix shm stuff over to a regression test I added some framework bits to manage the output format prove(1) expects. You can find it in src/tools/regression/posixshm/test.[ch]. I was curious if we wanted to perhaps make it a library in the base system (libbsdtest.a or some such) that our regression tools could use. The basic organization of the current test.[ch] is that you have a linker set of tests which it uses to number the tests and determine the test count. The framework provides routines for the test to indicate its result like so: pass() - indicates test passed fail() - indicates test failed with no error message fail_err(fmt, ...) - failure with printf(3) error message fail_errno(fmt, ...) - failure with error message followed by strerror(3) output similar to err(3) skip(const char *) - test skipped with reason for skip todo(const char *) - test marked as TODO If a given test doesn't call any of the status indicators above, then the main test loop will fail the test with an error of "unknown status". No effort is made to handle multiple status indications for a given test. I assume prove(1) would handle complaining about such anomalies in the test output. Tests consist of a void foo(void) function along with a description and each test is created via the TEST() macro like so: void mytest(void) { struct passwd *pwd; pwd = getpwuid(getuid()); if (strcmp(pwd->pw_name, "jhb") == 0) { fail_err("great evil detected"); return; } pass(); } TEST(mytest, "check for evil users"); To invoke the tests, one executes the 'run_tests()' method provided by the framework. It outputs the header expected by prove(1) and then executes each test in succession. I specifically didn't put main() in the framework in case a test utility wants to take optional arguments, etc. A simple test utility (like posixshm.c) just invokes run_tests() in its main(). One design decision that I'm sure will be debated is that I went with the functions to indicate results (fail, etc.) rather than having the test method return a value because it becomes more complicated to handle error messages otherwise. If this were C++ the tests could return a std::pair<> of a status code and some sort of object with a toString() method or something (or if it was python I would return a tuple). However, this is C. :) It's also nicer to be able to just pass the va args to vprintf() directly w/o having to print them into strings and print them out later, etc. Anyways, comments, etc.? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Jan 18 00:01:34 2008 Return-Path: Delivered-To: arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EC7016A417; Fri, 18 Jan 2008 00:01:34 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id 6099713C43E; Fri, 18 Jan 2008 00:01:34 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.2/8.14.1) with ESMTP id m0HNePSj086159; Thu, 17 Jan 2008 18:40:25 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.2/8.14.1/Submit) id m0HNePNJ086158; Thu, 17 Jan 2008 18:40:25 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 17 Jan 2008 18:40:25 -0500 From: David Schultz To: John Baldwin Message-ID: <20080117234025.GA86029@VARK.MIT.EDU> Mail-Followup-To: John Baldwin , arch@FreeBSD.ORG References: <200801171731.09873.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200801171731.09873.jhb@freebsd.org> Cc: arch@FreeBSD.ORG Subject: Re: Simple framework for regression tests in src/tools/regression X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2008 00:01:34 -0000 On Thu, Jan 17, 2008, John Baldwin wrote: > When I converted the test program for the posix shm stuff over to a regression > test I added some framework bits to manage the output format prove(1) > expects. You can find it in src/tools/regression/posixshm/test.[ch]. I was > curious if we wanted to perhaps make it a library in the base system > (libbsdtest.a or some such) that our regression tools could use. > > The basic organization of the current test.[ch] is that you have a linker set > of tests which it uses to number the tests and determine the test count. The > framework provides routines for the test to indicate its result like so: > > pass() - indicates test passed > fail() - indicates test failed with no error message > fail_err(fmt, ...) - failure with printf(3) error message > fail_errno(fmt, ...) - failure with error message followed by strerror(3) > output similar to err(3) > skip(const char *) - test skipped with reason for skip > todo(const char *) - test marked as TODO I think it would be great if some day we had an easy way to set up tools/regression so that all the tests get run by tinderbox automatically. I don't know if that has any impact on the design of what you propose. It would be nice if the library also provided an option (perhaps via an env variable) to make it possible to choose between a) printing a failure message and continuing b) calling abort() to trap into the debugger Also, add a drop-in replacement for assert() to the list above. Some of my tests call assert() because that happened to be convenient at the time, but that's not the right thing to do for prove(1). Also on my wish list: - A test infrastructure where you can type 'make' on level of the hierarchy and have it run all the tests under that directory; prove -r isn't flexible enough. It should be possible to skip tests that must be run as root and tests that only apply to certain architectures[1]. It should be possible to skip "long-running" tests, and it should be possible to specify some sort of abstract complexity parameter to tests that can run for arbitrary amounts of time. For example, I have a lot of libm tests that could run all day, but you wouldn't want to run them for more than a few seconds unless you had nothing better to do with the machine. - A good way to set up performance regression tests. This, of course, requires that the tests be run repeatedly on the same hardware. But on the library front, this means having a way to output measurements to a file somewhere and compare to previous measurements. (It might also mean convenience functions to gather timing and memory usage data, and routines to output platform configuration data automatically.) The Solaris kernel group has something like this. As I recall, they ran it on the same box nightly, and you could do things like generate a graph of fork latency for the previous few years, with different lines for different VCS branches. Not that we want to go that far, but it's something to think about... [1] A 'skip' library call might not be enough. Some tests might not even compile if they are for a different architecture. Another question is what if a test requires that a particular port be installed before it will run. Currently we simply don't allow dependencies like that, so for example, my libm tests that use ports/math/mpfr simply aren't checked in. But you could imagine being able to type 'make install-test-depends' and having all the right software get installed automagically; otherwise, the test infrastructure would notice that it is missing and refrain from attempting to compile the test. From owner-freebsd-arch@FreeBSD.ORG Fri Jan 18 01:36:58 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C072216A417; Fri, 18 Jan 2008 01:36:58 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE6213C4DD; Fri, 18 Jan 2008 01:36:58 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 42D581A4D8C; Thu, 17 Jan 2008 17:33:31 -0800 (PST) Date: Thu, 17 Jan 2008 17:33:31 -0800 From: Alfred Perlstein To: John Baldwin Message-ID: <20080118013331.GP99258@elvis.mu.org> References: <200801171731.09873.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200801171731.09873.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: Simple framework for regression tests in src/tools/regression X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2008 01:36:58 -0000 * John Baldwin [080117 14:28] wrote: > When I converted the test program for the posix shm stuff over to a regression > test I added some framework bits to manage the output format prove(1) > expects. You can find it in src/tools/regression/posixshm/test.[ch]. I was > curious if we wanted to perhaps make it a library in the base system > (libbsdtest.a or some such) that our regression tools could use. > > The basic organization of the current test.[ch] is that you have a linker set > of tests which it uses to number the tests and determine the test count. The > framework provides routines for the test to indicate its result like so: > > pass() - indicates test passed > fail() - indicates test failed with no error message > fail_err(fmt, ...) - failure with printf(3) error message > fail_errno(fmt, ...) - failure with error message followed by strerror(3) > output similar to err(3) > skip(const char *) - test skipped with reason for skip > todo(const char *) - test marked as TODO > > If a given test doesn't call any of the status indicators above, then the main > test loop will fail the test with an error of "unknown status". No effort is > made to handle multiple status indications for a given test. I assume > prove(1) would handle complaining about such anomalies in the test output. > > Tests consist of a void foo(void) function along with a description and each > test is created via the TEST() macro like so: > > void > mytest(void) > { > struct passwd *pwd; > > pwd = getpwuid(getuid()); > if (strcmp(pwd->pw_name, "jhb") == 0) { > fail_err("great evil detected"); > return; > } > pass(); > } > TEST(mytest, "check for evil users"); > > To invoke the tests, one executes the 'run_tests()' method provided by the > framework. It outputs the header expected by prove(1) and then executes each > test in succession. I specifically didn't put main() in the framework in > case a test utility wants to take optional arguments, etc. A simple test > utility (like posixshm.c) just invokes run_tests() in its main(). > > One design decision that I'm sure will be debated is that I went with the > functions to indicate results (fail, etc.) rather than having the test method > return a value because it becomes more complicated to handle error messages > otherwise. If this were C++ the tests could return a std::pair<> of a status > code and some sort of object with a toString() method or something (or if it > was python I would return a tuple). However, this is C. :) It's also nicer > to be able to just pass the va args to vprintf() directly w/o having to print > them into strings and print them out later, etc. > > Anyways, comments, etc.? There is C++ in the base system. You can return a pair by returning a structure which is supported in C. -Alfred From owner-freebsd-arch@FreeBSD.ORG Fri Jan 18 05:27:17 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDD6916A417 for ; Fri, 18 Jan 2008 05:27:17 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 287AB13C44B for ; Fri, 18 Jan 2008 05:27:16 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so1047416fgg.35 for ; Thu, 17 Jan 2008 21:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=48Hd3K1wvwP5mrK4Osqj3qS9mTN6q9/7YPrr67HEg0U=; b=SpPWOUMzWN+r/d7SdySRYYywYU7sCZr7ShCMdLEGNw+Peveg6NPlUxdcKov96HPLnfeeO6JIX1o/cZq3QUwT0jLIJ5n9PuEYXH8mpuj6k7G9JEWopepmi0bcTNd9nFVs1OVDIrO1r9KJPh8RDhIYGY8DOc9WPiefq4tjfduajoM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Mg6TnphEYgEI52DWVYBEhmaI/YyAvQQOgL7ErHO1t5tGMY80qJRI+kZ7ligp8zitmAP9x+JDypwYh7003UlMvzv16ZpVkHI8NqAK3e0UywZEAtezjz5ULW2GLRx/QDSAfrS9FtHX64ZwkE61awny45tGRPWMh/SXg+qj6qIVyN8= Received: by 10.86.58.3 with SMTP id g3mr2680669fga.38.1200632373536; Thu, 17 Jan 2008 20:59:33 -0800 (PST) Received: by 10.86.90.11 with HTTP; Thu, 17 Jan 2008 20:59:33 -0800 (PST) Message-ID: <84dead720801172059t22887e2di39fc911e5194ed60@mail.gmail.com> Date: Fri, 18 Jan 2008 10:29:33 +0530 From: "Joseph Koshy" To: "John Baldwin" In-Reply-To: <200801171731.09873.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200801171731.09873.jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Simple framework for regression tests in src/tools/regression X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2008 05:27:17 -0000 > When I converted the test program for the posix shm stuff over to a regression > test I added some framework bits to manage the output format prove(1) > expects. ...snip... > Anyways, comments, etc.? You could just use TET; its small, easy to use, compatibly licensed, stable, offers reasonable reporting, has a substantial user base. TET can also do far more than the typical 'home brew' test harness, if ever there is a need for that power. Regards, Koshy From owner-freebsd-arch@FreeBSD.ORG Fri Jan 18 14:45:50 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB82016A469 for ; Fri, 18 Jan 2008 14:45:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5A74D13C467 for ; Fri, 18 Jan 2008 14:45:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 053991A4D89; Fri, 18 Jan 2008 06:26:29 -0800 (PST) From: John Baldwin To: Alfred Perlstein Date: Fri, 18 Jan 2008 09:22:05 -0500 User-Agent: KMail/1.9.7 References: <200801171731.09873.jhb@freebsd.org> <20080118013331.GP99258@elvis.mu.org> In-Reply-To: <20080118013331.GP99258@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801180922.05736.jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Simple framework for regression tests in src/tools/regression X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2008 14:45:50 -0000 On Thursday 17 January 2008 08:33:31 pm Alfred Perlstein wrote: > * John Baldwin [080117 14:28] wrote: > > Anyways, comments, etc.? > > There is C++ in the base system. But none of our regression tools are written in it. I also must confess that std::pair<> is still a bit ugly though I could provide wrapper macros. > You can return a pair by returning a structure which is supported in > C. But the second part of the pair really needs to be an object. Error messages are printf style with var args, etc. I suppose I could do the whole asprintf() thing and end up with a 'return fail_err(...)' and have the status methods return a struct. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Jan 18 14:45:50 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADE8416A46B for ; Fri, 18 Jan 2008 14:45:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1D313C468 for ; Fri, 18 Jan 2008 14:45:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id DE77E1A4D7E; Fri, 18 Jan 2008 06:26:29 -0800 (PST) From: John Baldwin To: "Joseph Koshy" Date: Fri, 18 Jan 2008 09:23:21 -0500 User-Agent: KMail/1.9.7 References: <200801171731.09873.jhb@freebsd.org> <84dead720801172059t22887e2di39fc911e5194ed60@mail.gmail.com> In-Reply-To: <84dead720801172059t22887e2di39fc911e5194ed60@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801180923.21577.jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Simple framework for regression tests in src/tools/regression X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2008 14:45:50 -0000 On Thursday 17 January 2008 11:59:33 pm Joseph Koshy wrote: > > When I converted the test program for the posix shm stuff over to a regression > > test I added some framework bits to manage the output format prove(1) > > expects. > ...snip... > > Anyways, comments, etc.? > > You could just use TET; its small, easy to use, compatibly licensed, > stable, offers > reasonable reporting, has a substantial user base. TET can also do > far more than > the typical 'home brew' test harness, if ever there is a need for that power. Does it work with prove(1)? I'm just trying to make it easier to write conforming tests for our existing src/tools/regression infrastructure, don't really have the cycles to switch it over to some other framework. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Jan 18 17:30:55 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F06816A419; Fri, 18 Jan 2008 17:30:55 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6696213C4E1; Fri, 18 Jan 2008 17:30:55 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 7F9451A4D7E; Fri, 18 Jan 2008 09:27:24 -0800 (PST) Date: Fri, 18 Jan 2008 09:27:24 -0800 From: Alfred Perlstein To: John Baldwin Message-ID: <20080118172724.GS99258@elvis.mu.org> References: <200801171731.09873.jhb@freebsd.org> <20080118013331.GP99258@elvis.mu.org> <200801180922.05736.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200801180922.05736.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: Simple framework for regression tests in src/tools/regression X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2008 17:30:55 -0000 * John Baldwin [080118 06:42] wrote: > On Thursday 17 January 2008 08:33:31 pm Alfred Perlstein wrote: > > * John Baldwin [080117 14:28] wrote: > > > Anyways, comments, etc.? > > > > There is C++ in the base system. > > But none of our regression tools are written in it. I also must confess that > std::pair<> is still a bit ugly though I could provide wrapper macros. > > > You can return a pair by returning a structure which is supported in > > C. > > But the second part of the pair really needs to be an object. Error messages > are printf style with var args, etc. I suppose I could do the whole asprintf() > thing and end up with a 'return fail_err(...)' and have the status methods > return a struct. It's not that big of a deal. go with what works. -alfred From owner-freebsd-arch@FreeBSD.ORG Sat Jan 19 08:08:30 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 406D316A417; Sat, 19 Jan 2008 08:08:30 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id E721713C45D; Sat, 19 Jan 2008 08:08:24 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id m0IHHto7037044; Fri, 18 Jan 2008 12:17:55 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-arch@FreeBSD.org Date: Fri, 18 Jan 2008 12:17:46 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200801181217.52788.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.92/5494/Fri Jan 18 09:23:47 2008 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: [RFC] SysV SHM on 64-bit platforms X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2008 08:08:30 -0000 While I was working on kern/113218, I realized it is a bigger problem than I originally thought: http://www.freebsd.org/cgi/query-pr.cgi?pr=113218 Because fixing this PR breaks ABI, I had to make compat shims. But the question is which branch to break? Since we are very close to 7.0-RELEASE, the question became more complicated. A lot of people are asking me to fix this PR because it is much needed fix for large database installations, so I have to make a quick decision. :-( I think I have four options (with corresponding patches): - Option 1: HEAD. HEAD: http://people.freebsd.org/~jkim/shmmax8o.diff - Option 2: HEAD and RELENG_7. HEAD: http://people.freebsd.org/~jkim/shmmax8c2.diff RELENG_7: http://people.freebsd.org/~jkim/shmmax7s2.diff - Option 3: HEAD, RELENG_7, and RELENG_7_0. HEAD: http://people.freebsd.org/~jkim/shmmax8c.diff RELENG_7: http://people.freebsd.org/~jkim/shmmax7s.diff RELENG_7_0: http://people.freebsd.org/~jkim/shmmax70.diff - Option 4: Don't do anything ATM. Break it with ipc_perm later. FYI, fixing ipc_perm is a lot more complicated and very intrusive. What do I do now? Do I have any other options? Jung-uk Kim From owner-freebsd-arch@FreeBSD.ORG Sat Jan 19 12:30:31 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 555DF16A41A for ; Sat, 19 Jan 2008 12:30:31 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3E57C13C457 for ; Sat, 19 Jan 2008 12:30:31 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 67A5F1A4D7E; Sat, 19 Jan 2008 04:26:57 -0800 (PST) Date: Sat, 19 Jan 2008 04:26:57 -0800 From: Alfred Perlstein To: Jung-uk Kim Message-ID: <20080119122657.GN99258@elvis.mu.org> References: <200801181217.52788.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200801181217.52788.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [RFC] SysV SHM on 64-bit platforms X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2008 12:30:31 -0000 * Jung-uk Kim [080119 00:05] wrote: > While I was working on kern/113218, I realized it is a bigger problem > than I originally thought: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=113218 > > Because fixing this PR breaks ABI, I had to make compat shims. But > the question is which branch to break? Since we are very close to > 7.0-RELEASE, the question became more complicated. A lot of people > are asking me to fix this PR because it is much needed fix for large > database installations, so I have to make a quick decision. :-( I think this is a step forward so it's not so bad, just make sure to talk to "re@" about your MFCs, if it'll work out. > > I think I have four options (with corresponding patches): > - Option 1: HEAD. > - Option 2: HEAD and RELENG_7. > - Option 3: HEAD, RELENG_7, and RELENG_7_0. > - Option 4: Don't do anything ATM. Break it with ipc_perm later. I like option 3 if possible. > FYI, fixing ipc_perm is a lot more complicated and very intrusive. Why does ipc_perm need fixing? -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Sat Jan 19 12:31:40 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56DC216A419; Sat, 19 Jan 2008 12:31:40 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id 148D413C458; Sat, 19 Jan 2008 12:31:39 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.2/8.14.1) with ESMTP id m0JCDGsn022194; Sat, 19 Jan 2008 07:13:16 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.2/8.14.1/Submit) id m0JCDG1B022193; Sat, 19 Jan 2008 07:13:16 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Sat, 19 Jan 2008 07:13:16 -0500 From: David Schultz To: Jung-uk Kim Message-ID: <20080119121316.GA21917@VARK.MIT.EDU> Mail-Followup-To: Jung-uk Kim , freebsd-arch@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <200801181217.52788.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200801181217.52788.jkim@FreeBSD.org> Cc: freebsd-current@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] SysV SHM on 64-bit platforms X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2008 12:31:40 -0000 On Fri, Jan 18, 2008, Jung-uk Kim wrote: > Because fixing this PR breaks ABI, I had to make compat shims. But > the question is which branch to break? Since we are very close to > 7.0-RELEASE, the question became more complicated. A lot of people > are asking me to fix this PR because it is much needed fix for large > database installations, so I have to make a quick decision. :-( It's far too late to fix it for 7.0. RC1 is out, the packages have already been built, and this could potentially break things. In particular, you have no way of guaranteeing that an "old" shared library that uses semctl(2) linked with a "new" binary will work properly, or vise versa. For 8-CURRENT, I'd say go ahead and fix it and add the syscall compat goop. Then I guess backport it to 7-STABLE after a while if nothing important breaks and nobody has any objections to that plan. It would also be cool if struct ipcperm got fixed at the same time so we only have to do this once. I think that only entails adding compat crud to semctl and maybe one or two other syscalls. Those changes aren't urgent enough to make it worthwhile to backport to 7.X IMO, though. Two questions/comments about the patches: - Why the #if !defined(__i386__)? There are better ways to test whether you're compiling for a 32-bit architecture, if that's what you meant. - The 8.X version needs to take the p_osrel for the equivalent change in 7.X into account. From owner-freebsd-arch@FreeBSD.ORG Sat Jan 19 15:05:02 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5C4816A418; Sat, 19 Jan 2008 15:05:02 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from gw.sandvine.com (gw.sandvine.com [199.243.201.138]) by mx1.freebsd.org (Postfix) with ESMTP id 7928B13C4E1; Sat, 19 Jan 2008 15:05:02 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by gw.sandvine.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Jan 2008 09:52:59 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 726BD11613; Sat, 19 Jan 2008 09:52:59 -0500 (EST) Date: Sat, 19 Jan 2008 09:52:59 -0500 From: Ed Maste To: Alfred Perlstein Message-ID: <20080119145259.GA36194@sandvine.com> References: <200801181217.52788.jkim@FreeBSD.org> <20080119122657.GN99258@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080119122657.GN99258@elvis.mu.org> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 19 Jan 2008 14:52:59.0646 (UTC) FILETIME=[FBDB69E0:01C85AAA] Cc: freebsd-current@FreeBSD.org, Jung-uk Kim , freebsd-arch@FreeBSD.org Subject: Re: [RFC] SysV SHM on 64-bit platforms X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2008 15:05:02 -0000 On Sat, Jan 19, 2008 at 04:26:57AM -0800, Alfred Perlstein wrote: > * Jung-uk Kim [080119 00:05] wrote: > > FYI, fixing ipc_perm is a lot more complicated and very intrusive. > > Why does ipc_perm need fixing? Most of the types in ipc_perm have the wrong type. There's even an XXX comment in ipc.h saying as much. We really need to fix both issues at the same time though. -Ed From owner-freebsd-arch@FreeBSD.ORG Sat Jan 19 15:42:42 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A73616A41B; Sat, 19 Jan 2008 15:42:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id BE13913C458; Sat, 19 Jan 2008 15:42:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5074E46D1E; Sat, 19 Jan 2008 10:42:41 -0500 (EST) Date: Sat, 19 Jan 2008 15:42:41 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alfred Perlstein In-Reply-To: <20080119122657.GN99258@elvis.mu.org> Message-ID: <20080119154147.E91115@fledge.watson.org> References: <200801181217.52788.jkim@FreeBSD.org> <20080119122657.GN99258@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, Jung-uk Kim , freebsd-arch@FreeBSD.org Subject: Re: [RFC] SysV SHM on 64-bit platforms X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2008 15:42:42 -0000 On Sat, 19 Jan 2008, Alfred Perlstein wrote: >> FYI, fixing ipc_perm is a lot more complicated and very intrusive. > > Why does ipc_perm need fixing? It is desparately broken due to using 16-bit types for uids and gids. Fixing it really tears up the ABI, unfortunately, and requires quite a bit of compat code writing. When there, there are some other types in ipc_perm that would also like to be fixed. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Sat Jan 19 22:06:49 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13BB316A421; Sat, 19 Jan 2008 22:06:49 +0000 (UTC) (envelope-from nik@ngo.org.uk) Received: from jc.ngo.org.uk (jc.ngo.org.uk [69.55.225.33]) by mx1.freebsd.org (Postfix) with ESMTP id 07B0C13C46B; Sat, 19 Jan 2008 22:06:48 +0000 (UTC) (envelope-from nik@ngo.org.uk) Received: from [192.168.3.3] (25-115.77-83.cust.bluewin.ch [83.77.115.25]) by jc.ngo.org.uk (8.13.8/8.13.8) with ESMTP id m0JLnln8061288; Sat, 19 Jan 2008 13:50:18 -0800 (PST) (envelope-from nik@ngo.org.uk) Message-ID: <47927085.4020604@ngo.org.uk> Date: Sat, 19 Jan 2008 22:49:57 +0100 From: nik User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: John Baldwin References: <200801171731.09873.jhb@freebsd.org> In-Reply-To: <200801171731.09873.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: * (1.988) RCVD_IN_SORBS_DUL X-Scanned-By: MIMEDefang 2.57 on 69.55.225.33 Cc: arch@freebsd.org, rusty@rustcorp.com.au Subject: Re: Simple framework for regression tests in src/tools/regression X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2008 22:06:49 -0000 John Baldwin wrote: > When I converted the test program for the posix shm stuff over to a regression > test I added some framework bits to manage the output format prove(1) > expects. You can find it in src/tools/regression/posixshm/test.[ch]. I was > curious if we wanted to perhaps make it a library in the base system > (libbsdtest.a or some such) that our regression tools could use. You want libtap(3), which outputs the necessary format. I wrote it, then got caught up with other things, and now Rusty Russel (rusty@rustcorp.com.au, copied) maintains it. There's a repo at http://ccan.ozlabs.org/repo/ccan_tools/libtap/ -- IIRC there's also a port (which probably needs updating). N