From owner-freebsd-arch@FreeBSD.ORG Mon Sep 19 03:37:44 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6871016A41F; Mon, 19 Sep 2005 03:37:44 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 431CA43D48; Mon, 19 Sep 2005 03:37:43 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [211.71.95.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id EE576EB08D7; Mon, 19 Sep 2005 11:37:37 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id DCD5413159E; Mon, 19 Sep 2005 11:37:33 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84846-16; Mon, 19 Sep 2005 11:37:24 +0800 (CST) Received: from [10.217.12.235] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id 214D3130C42; Mon, 19 Sep 2005 11:37:24 +0800 (CST) From: Xin LI To: freebsd-arch@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MlGidjHbWMxS/2Zg/9Vh" Organization: The FreeBSD Simplified Chinese Project Date: Mon, 19 Sep 2005 11:37:22 +0800 Message-Id: <1127101042.788.30.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at frontfree.net Cc: freebsd-performance@FreeBSD.org Subject: Combine more operation within one system call: to do it, or not to do it? 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, 19 Sep 2005 03:37:44 -0000 --=-MlGidjHbWMxS/2Zg/9Vh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Dear folks, It seems that Microsoft has recently revised several of their APIs. One example is their ConnectEx(), as found in documentation [1]. The implementation is not so complex that it just combines more operation within one system call, however, this can reduce some unnecessary context switches as it's now possible to do more things within one system call. (For instance, when you connect to a server, you usually want to send some data as request). Shall we do something similar? Or do we already done something similar? [1] http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/winsock/= winsock/connectex_2.asp Cheers, --=20 Xin LI http://www.delphij.net/ --=-MlGidjHbWMxS/2Zg/9Vh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDLjJy/cVsHxFZiIoRAssxAKCD3rV/yiXY//MqGAMqNT6NjCpe0wCeMQ1V qlRLNc56p9nQwrCPLiBG7/E= =ZTQ/ -----END PGP SIGNATURE----- --=-MlGidjHbWMxS/2Zg/9Vh-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 19 09:42:43 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 035F816A41F; Mon, 19 Sep 2005 09:42:43 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A1C843D45; Mon, 19 Sep 2005 09:42:41 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail16.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j8J9gb4S007845 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 19 Sep 2005 19:42:39 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j8J9gaSR054941; Mon, 19 Sep 2005 19:42:36 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j8J9gZ3j054940; Mon, 19 Sep 2005 19:42:35 +1000 (EST) (envelope-from pjeremy) Date: Mon, 19 Sep 2005 19:42:34 +1000 From: Peter Jeremy To: Xin LI Message-ID: <20050919094234.GG40237@cirb503493.alcatel.com.au> References: <1127101042.788.30.camel@spirit> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1127101042.788.30.camel@spirit> User-Agent: Mutt/1.4.2.1i Cc: freebsd-performance@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Combine more operation within one system call: to do it, or not to do it? 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, 19 Sep 2005 09:42:43 -0000 On Mon, 2005-Sep-19 11:37:22 +0800, Xin LI wrote: >It seems that Microsoft has recently revised several of their APIs. I think this is a regular occurence as part of their ongoing efforts to minimise backward and forward compatibility. > One example is their ConnectEx(), as found in documentation [1]. Does this represent a measurable improvement in a real-world situation? >Shall we do something similar? Looking at it from the application writer's POV: Implementing a special case for one OS (when that OS also supports the standard mechanism) requires additional effort and there needs to be good justification for expending that effort. Overall, orphan functionality is unlikely to be used. Unless you can convince several other vendors (*BSD, Linux or a commercial vendor) that the same functionality is worth implementing, you're better off not bothering. > Or do we already done something similar? How about sendto(2)? >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/connectex_2.asp This doesn't work with lynx and I don't have my mozilla running. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Tue Sep 20 02:34:27 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31D6916A41F; Tue, 20 Sep 2005 02:34:27 +0000 (GMT) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8948343D46; Tue, 20 Sep 2005 02:34:26 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 451E82A945; Mon, 19 Sep 2005 19:34:26 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id B5935E2B3; Mon, 19 Sep 2005 19:34:25 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.4/8.13.4) with ESMTP id j8K2YPpF041974; Mon, 19 Sep 2005 19:34:25 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.4/8.13.1/Submit) id j8K2YOhk041971; Mon, 19 Sep 2005 19:34:24 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-arch@freebsd.org Date: Mon, 19 Sep 2005 19:34:23 -0700 User-Agent: KMail/1.8.1 References: <1127101042.788.30.camel@spirit> <20050919094234.GG40237@cirb503493.alcatel.com.au> In-Reply-To: <20050919094234.GG40237@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509191934.23991.peter@wemm.org> Cc: Peter Jeremy , freebsd-performance@freebsd.org Subject: Re: Combine more operation within one system call: to do it, or not to do it? 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, 20 Sep 2005 02:34:27 -0000 On Monday 19 September 2005 02:42 am, Peter Jeremy wrote: > On Mon, 2005-Sep-19 11:37:22 +0800, Xin LI wrote: > >It seems that Microsoft has recently revised several of their APIs. > > I think this is a regular occurence as part of their ongoing efforts > to minimise backward and forward compatibility. > > > One example is their ConnectEx(), as found in documentation [1]. > > Does this represent a measurable improvement in a real-world > situation? The other consideration is that our syscalls are generally pretty quick on most of our platforms. We don't normally context switch for a syscall - well, we save and restore registers, but that isn't too bad compared to the i386 tss and ldt etc switches for process context switches. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Tue Sep 20 11:20:23 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 744F916A41F for ; Tue, 20 Sep 2005 11:20:23 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id A901943D48 for ; Tue, 20 Sep 2005 11:20:22 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 58D98BC66 for ; Tue, 20 Sep 2005 11:20:20 +0000 (UTC) To: arch@freebsd.org From: Poul-Henning Kamp Date: Tue, 20 Sep 2005 11:20:19 +0000 Message-ID: <5975.1127215219@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: Improving bus/resource API 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, 20 Sep 2005 11:20:23 -0000 The patch below improves the bus/resource API such that between 10 and 20 lines of code can be eliminated from the attach/detach functions of the average device driver. Therefore the best place to start is to read what the patch does to if_sis.c, which is a very typical case. The patch is backwards compatible in binary and source form so it is a potential candidate for RELENG_6 at some point. Compile tested on i386/amd64 and sparc64. My alpha will be chewing on it for the forseeable future. For sanity in the ensuing bikeshed, let's take three topics in this order: 1. "what this does to the device driver sources." 2. "what this does to the rman/bus internals" 3. "suggestions for different function names" Poul-Henning Patch Description, first part: Add the bus_dwiw_alloc()/bus_dwiw_release() functions which will allocate and release a set of resources for a given device. XXX: To avoid circular #include dependencies, move the device_t XXX: typedef to sys/param.h. A better solution may exist. Patch Description, second part: Split struct resource into a private (struct resource_i) and a public part (struct resource). The public part is a substructure of the private part to which it has a backpointer. Expose the public structure, but keep the private structure hidden as before. Move the bustag and bushandle elements from the private to the public structure. Add bsr_[124]() and bsw_[124]() macros which take a struct resource pointer instead of bustag+bushandle arguments. This allows many drivers to never worry about the bustag/bushandles. Patch Description, third part: Convert the if_sis.c driver. (Good example) Convert the tnt4882.c driver (Less perfect example). Index: amd64/include/bus.h =================================================================== RCS file: /home/ncvs/src/sys/amd64/include/bus.h,v retrieving revision 1.16 diff -u -r1.16 bus.h --- amd64/include/bus.h 29 May 2005 04:42:15 -0000 1.16 +++ amd64/include/bus.h 20 Sep 2005 11:00:52 -0000 @@ -221,6 +221,8 @@ return (*(volatile u_int8_t *)(handle + offset)); } +#define bsr_1(r,o) bus_space_read_1((r)->r_bustag, (r)->r_bushandle, (o)) + static __inline u_int16_t bus_space_read_2(bus_space_tag_t tag, bus_space_handle_t handle, bus_size_t offset) @@ -231,6 +233,8 @@ return (*(volatile u_int16_t *)(handle + offset)); } +#define bsr_2(r,o) bus_space_read_2((r)->r_bustag, (r)->r_bushandle, (o)) + static __inline u_int32_t bus_space_read_4(bus_space_tag_t tag, bus_space_handle_t handle, bus_size_t offset) @@ -241,6 +245,8 @@ return (*(volatile u_int32_t *)(handle + offset)); } +#define bsr_4(r,o) bus_space_read_4((r)->r_bustag, (r)->r_bushandle, (o)) + #if 0 /* Cause a link error for bus_space_read_8 */ #define bus_space_read_8(t, h, o) !!! bus_space_read_8 unimplemented !!! #endif @@ -480,6 +486,8 @@ *(volatile u_int8_t *)(bsh + offset) = value; } +#define bsw_1(r,o,v) bus_space_write_1((r)->r_bustag, (r)->r_bushandle, (o), (v)) + static __inline void bus_space_write_2(bus_space_tag_t tag, bus_space_handle_t bsh, bus_size_t offset, u_int16_t value) @@ -491,6 +499,8 @@ *(volatile u_int16_t *)(bsh + offset) = value; } +#define bsw_2(r,o,v) bus_space_write_2((r)->r_bustag, (r)->r_bushandle, (o), (v)) + static __inline void bus_space_write_4(bus_space_tag_t tag, bus_space_handle_t bsh, bus_size_t offset, u_int32_t value) @@ -502,6 +512,8 @@ *(volatile u_int32_t *)(bsh + offset) = value; } +#define bsw_4(r,o,v) bus_space_write_4((r)->r_bustag, (r)->r_bushandle, (o), (v)) + #if 0 /* Cause a link error for bus_space_write_8 */ #define bus_space_write_8 !!! bus_space_write_8 not implemented !!! #endif Index: dev/ieee488/tnt4882.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ieee488/tnt4882.c,v retrieving revision 1.1 diff -u -r1.1 tnt4882.c --- dev/ieee488/tnt4882.c 15 Sep 2005 13:27:16 -0000 1.1 +++ dev/ieee488/tnt4882.c 20 Sep 2005 11:00:52 -0000 @@ -51,12 +51,17 @@ int foo; struct upd7210 upd7210; - struct resource *res0, *res1, *res2; - bus_space_tag_t bt0, bt1; - bus_space_handle_t bh0, bh1; + struct resource *res[3]; void *intr_handler; }; +static struct resource_spec tnt_res_spec[] = { + { SYS_RES_MEMORY, PCIR_BAR(0) }, + { SYS_RES_MEMORY, PCIR_BAR(1) }, + { SYS_RES_IRQ, 0 }, + { -1, 0 } +}; + enum tnt4882reg { dir = 0x00, cdor = 0x00, @@ -229,10 +234,10 @@ for (step = 0; tp->action != END; tp++, step++) { switch (tp->action) { case WT: - bus_space_write_1(sc->bt1, sc->bh1, tp->reg, tp->val); + bsw_1(sc->res[1], tp->reg, tp->val); break; case RD: - u = bus_space_read_1(sc->bt1, sc->bh1, tp->reg); + u = bsr_1(sc->res[1], tp->reg); if (u != tp->val) { printf( "Test %s, step %d: reg(%02x) = %02x", @@ -256,56 +261,6 @@ } static int -bus_dwiw(device_t dev, ...) -{ - va_list ap, ap2; - int rid; - int type; - int flags; - struct resource **rp; - bus_space_tag_t *bt; - bus_space_handle_t *bh; - - va_start(ap, dev); - va_copy(ap2, ap); - while (1) { - type = va_arg(ap, int); - if (type == -1) { - va_end(ap); - return (0); - } - rid = va_arg(ap, int); - flags = va_arg(ap, int); - rp = va_arg(ap, struct resource **); - *rp = bus_alloc_resource_any(dev, type, &rid, flags); - if (*rp == NULL) - break; - if (type == SYS_RES_IOPORT || type == SYS_RES_MEMORY) { - bt = va_arg(ap, bus_space_tag_t *); - *bt = rman_get_bustag(*rp); - bh = va_arg(ap, bus_space_handle_t *); - *bh = rman_get_bushandle(*rp); - } - } - while (1) { - type = va_arg(ap2, int); - KASSERT(type != -1, ("bus_dwiw() internal mess")); - rid = va_arg(ap2, int); - flags = va_arg(ap2, int); - rp = va_arg(ap2, struct resource **); - if (*rp != NULL) - bus_release_resource(dev, type, rid, *rp); - else { - va_end(ap2); - return (ENXIO); - } - if (type == SYS_RES_IOPORT || type == SYS_RES_MEMORY) { - bt = va_arg(ap2, bus_space_tag_t *); - bh = va_arg(ap2, bus_space_handle_t *); - } - } -} -static int tnt_probe(device_t dev) { @@ -324,21 +279,15 @@ sc = device_get_softc(dev); - error = bus_dwiw(dev, - SYS_RES_MEMORY, PCIR_BAR(0), RF_ACTIVE, - &sc->res0, &sc->bt0, &sc->bh0, - SYS_RES_MEMORY, PCIR_BAR(1), RF_ACTIVE, - &sc->res1, &sc->bt1, &sc->bh1, - SYS_RES_IRQ, 0, RF_ACTIVE | RF_SHAREABLE, &sc->res2, - -1); + error = bus_dwiw_alloc(dev, tnt_res_spec, sc->res); if (error) return (error); - error = bus_setup_intr(dev, sc->res2, INTR_TYPE_MISC | INTR_MPSAFE, + error = bus_setup_intr(dev, sc->res[2], INTR_TYPE_MISC | INTR_MPSAFE, upd7210intr, &sc->upd7210, &sc->intr_handler); /* Necessary magic for MITE */ - bus_space_write_4(sc->bt0, sc->bh0, 0xc0, vtophys(sc->bh1) | 0x80); + bsw_4(sc->res[0], 0xc0, rman_get_start(sc->res[1]) | 0x80); tst_exec(sc, tst_reset, "Reset"); tst_exec(sc, tst_read_reg, "Read registers"); @@ -350,11 +299,11 @@ tst_exec(sc, tst_reset, "Reset"); /* pass 7210 interrupts through */ - bus_space_write_1(sc->bt1, sc->bh1, imr3, 0x02); + bsw_1(sc->res[1], imr3, 0x02); for (i = 0; i < 8; i++) { - sc->upd7210.reg_tag[i] = sc->bt1; - sc->upd7210.reg_handle[i] = sc->bh1; + sc->upd7210.reg_tag[i] = rman_get_bustag(sc->res[1]); + sc->upd7210.reg_handle[i] = rman_get_bushandle(sc->res[1]); sc->upd7210.reg_offset[i] = i * 2; } @@ -372,12 +321,10 @@ struct tnt_softc *sc; sc = device_get_softc(dev); - bus_teardown_intr(dev, sc->res2, sc->intr_handler); + bus_teardown_intr(dev, sc->res[2], sc->intr_handler); upd7210detach(&sc->upd7210); - bus_release_resource(dev, SYS_RES_MEMORY, PCIR_BAR(0), sc->res0); - bus_release_resource(dev, SYS_RES_MEMORY, PCIR_BAR(1), sc->res1); - bus_release_resource(dev, SYS_RES_IRQ, 0, sc->res2); + bus_dwiw_release(dev, tnt_res_spec, sc->res); return (0); } Index: i386/include/bus.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/bus.h,v retrieving revision 1.13 diff -u -r1.13 bus.h --- i386/include/bus.h 29 May 2005 04:42:28 -0000 1.13 +++ i386/include/bus.h 20 Sep 2005 11:00:52 -0000 @@ -225,6 +225,8 @@ return (*(volatile u_int8_t *)(handle + offset)); } +#define bsr_1(r,o) bus_space_read_1((r)->r_bustag, (r)->r_bushandle, (o)) + static __inline u_int16_t bus_space_read_2(bus_space_tag_t tag, bus_space_handle_t handle, bus_size_t offset) @@ -235,6 +237,8 @@ return (*(volatile u_int16_t *)(handle + offset)); } +#define bsr_2(r,o) bus_space_read_2((r)->r_bustag, (r)->r_bushandle, (o)) + static __inline u_int32_t bus_space_read_4(bus_space_tag_t tag, bus_space_handle_t handle, bus_size_t offset) @@ -245,6 +249,8 @@ return (*(volatile u_int32_t *)(handle + offset)); } +#define bsr_4(r,o) bus_space_read_4((r)->r_bustag, (r)->r_bushandle, (o)) + #if 0 /* Cause a link error for bus_space_read_8 */ #define bus_space_read_8(t, h, o) !!! bus_space_read_8 unimplemented !!! #endif @@ -519,6 +525,7 @@ else *(volatile u_int8_t *)(bsh + offset) = value; } +#define bsw_1(r,o,v) bus_space_write_1((r)->r_bustag, (r)->r_bushandle, (o), (v)) static __inline void bus_space_write_2(bus_space_tag_t tag, bus_space_handle_t bsh, @@ -531,6 +538,8 @@ *(volatile u_int16_t *)(bsh + offset) = value; } +#define bsw_2(r,o,v) bus_space_write_2((r)->r_bustag, (r)->r_bushandle, (o), (v)) + static __inline void bus_space_write_4(bus_space_tag_t tag, bus_space_handle_t bsh, bus_size_t offset, u_int32_t value) @@ -542,6 +551,8 @@ *(volatile u_int32_t *)(bsh + offset) = value; } +#define bsw_4(r,o,v) bus_space_write_4((r)->r_bustag, (r)->r_bushandle, (o), (v)) + #if 0 /* Cause a link error for bus_space_write_8 */ #define bus_space_write_8 !!! bus_space_write_8 not implemented !!! #endif Index: kern/subr_rman.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_rman.c,v retrieving revision 1.43 diff -u -r1.43 subr_rman.c --- kern/subr_rman.c 6 May 2005 02:48:20 -0000 1.43 +++ kern/subr_rman.c 20 Sep 2005 11:00:52 -0000 @@ -81,10 +81,22 @@ struct rman_head rman_head; static struct mtx rman_mtx; /* mutex to protect rman_head */ -static int int_rman_activate_resource(struct rman *rm, struct resource *r, - struct resource **whohas); -static int int_rman_deactivate_resource(struct resource *r); -static int int_rman_release_resource(struct rman *rm, struct resource *r); +static int int_rman_activate_resource(struct rman *rm, struct resource_i *r, + struct resource_i **whohas); +static int int_rman_deactivate_resource(struct resource_i *r); +static int int_rman_release_resource(struct rman *rm, struct resource_i *r); + +static __inline struct resource_i * +int_alloc_resource(int malloc_flag) +{ + struct resource_i *r; + + r = malloc(sizeof *r, M_RMAN, malloc_flag | M_ZERO); + if (r != NULL) { + r->r_r.__r_i = r; + } + return (r); +} int rman_init(struct rman *rm) @@ -121,11 +133,11 @@ int rman_manage_region(struct rman *rm, u_long start, u_long end) { - struct resource *r, *s; + struct resource_i *r, *s; DPRINTF(("rman_manage_region: <%s> request: start %#lx, end %#lx\n", rm->rm_descr, start, end)); - r = malloc(sizeof *r, M_RMAN, M_NOWAIT | M_ZERO); + r = int_alloc_resource(M_NOWAIT); if (r == 0) return ENOMEM; r->r_start = start; @@ -151,7 +163,7 @@ int rman_fini(struct rman *rm) { - struct resource *r; + struct resource_i *r; mtx_lock(rm->rm_mtx); TAILQ_FOREACH(r, &rm->rm_list, r_link) { @@ -186,7 +198,7 @@ struct device *dev) { u_int want_activate; - struct resource *r, *s, *rv; + struct resource_i *r, *s, *rv; u_long rstart, rend, amask, bmask; rv = 0; @@ -267,7 +279,7 @@ * split it in two. The first case requires * two new allocations; the second requires but one. */ - rv = malloc(sizeof *rv, M_RMAN, M_NOWAIT | M_ZERO); + rv = int_alloc_resource(M_NOWAIT); if (rv == 0) goto out; rv->r_start = rstart; @@ -285,7 +297,7 @@ /* * We are allocating in the middle. */ - r = malloc(sizeof *r, M_RMAN, M_NOWAIT|M_ZERO); + r = int_alloc_resource(M_NOWAIT); if (r == 0) { free(rv, M_RMAN); rv = 0; @@ -343,7 +355,7 @@ && (s->r_end - s->r_start + 1) == count && (s->r_start & amask) == 0 && ((s->r_start ^ s->r_end) & bmask) == 0) { - rv = malloc(sizeof *rv, M_RMAN, M_NOWAIT | M_ZERO); + rv = int_alloc_resource(M_NOWAIT); if (rv == 0) goto out; rv->r_start = s->r_start; @@ -383,7 +395,7 @@ * make sense for RF_TIMESHARE-type resources.) */ if (rv && want_activate) { - struct resource *whohas; + struct resource_i *whohas; if (int_rman_activate_resource(rm, rv, &whohas)) { int_rman_release_resource(rm, rv); rv = 0; @@ -391,7 +403,7 @@ } mtx_unlock(rm->rm_mtx); - return (rv); + return (&rv->r_r); } struct resource * @@ -404,10 +416,10 @@ } static int -int_rman_activate_resource(struct rman *rm, struct resource *r, - struct resource **whohas) +int_rman_activate_resource(struct rman *rm, struct resource_i *r, + struct resource_i **whohas) { - struct resource *s; + struct resource_i *s; int ok; /* @@ -439,12 +451,13 @@ } int -rman_activate_resource(struct resource *r) +rman_activate_resource(struct resource *re) { int rv; - struct resource *whohas; + struct resource_i *r, *whohas; struct rman *rm; + r = re->__r_i; rm = r->r_rm; mtx_lock(rm->rm_mtx); rv = int_rman_activate_resource(rm, r, &whohas); @@ -453,12 +466,13 @@ } int -rman_await_resource(struct resource *r, int pri, int timo) +rman_await_resource(struct resource *re, int pri, int timo) { int rv; - struct resource *whohas; + struct resource_i *r, *whohas; struct rman *rm; + r = re->__r_i; rm = r->r_rm; mtx_lock(rm->rm_mtx); for (;;) { @@ -478,7 +492,7 @@ } static int -int_rman_deactivate_resource(struct resource *r) +int_rman_deactivate_resource(struct resource_i *r) { r->r_flags &= ~RF_ACTIVE; @@ -494,17 +508,17 @@ { struct rman *rm; - rm = r->r_rm; + rm = r->__r_i->r_rm; mtx_lock(rm->rm_mtx); - int_rman_deactivate_resource(r); + int_rman_deactivate_resource(r->__r_i); mtx_unlock(rm->rm_mtx); return 0; } static int -int_rman_release_resource(struct rman *rm, struct resource *r) +int_rman_release_resource(struct rman *rm, struct resource_i *r) { - struct resource *s, *t; + struct resource_i *s, *t; if (r->r_flags & RF_ACTIVE) int_rman_deactivate_resource(r); @@ -595,11 +609,14 @@ } int -rman_release_resource(struct resource *r) +rman_release_resource(struct resource *re) { int rv; - struct rman *rm = r->r_rm; + struct resource_i *r; + struct rman *rm; + r = re->__r_i; + rm = r->r_rm; mtx_lock(rm->rm_mtx); rv = int_rman_release_resource(rm, r); mtx_unlock(rm->rm_mtx); @@ -627,37 +644,37 @@ u_long rman_get_start(struct resource *r) { - return (r->r_start); + return (r->__r_i->r_start); } u_long rman_get_end(struct resource *r) { - return (r->r_end); + return (r->__r_i->r_end); } u_long rman_get_size(struct resource *r) { - return (r->r_end - r->r_start + 1); + return (r->__r_i->r_end - r->__r_i->r_start + 1); } u_int rman_get_flags(struct resource *r) { - return (r->r_flags); + return (r->__r_i->r_flags); } void rman_set_virtual(struct resource *r, void *v) { - r->r_virtual = v; + r->__r_i->r_virtual = v; } void * rman_get_virtual(struct resource *r) { - return (r->r_virtual); + return (r->__r_i->r_virtual); } void @@ -687,37 +704,69 @@ void rman_set_rid(struct resource *r, int rid) { - r->r_rid = rid; + r->__r_i->r_rid = rid; } void rman_set_start(struct resource *r, u_long start) { - r->r_start = start; + r->__r_i->r_start = start; } void rman_set_end(struct resource *r, u_long end) { - r->r_end = end; + r->__r_i->r_end = end; } int rman_get_rid(struct resource *r) { - return (r->r_rid); + return (r->__r_i->r_rid); } struct device * rman_get_device(struct resource *r) { - return (r->r_dev); + return (r->__r_i->r_dev); } void rman_set_device(struct resource *r, struct device *dev) { - r->r_dev = dev; + r->__r_i->r_dev = dev; +} + +/* + * Device driver convenience functions + */ + +int +bus_dwiw_alloc(device_t dev, struct resource_spec *rs, struct resource **res) +{ + int i; + + for (i = 0; rs[i].type != -1; i++) + res[i] = NULL; + for (i = 0; rs[i].type != -1; i++) { + res[i] = bus_alloc_resource_any(dev, + rs[i].type, &rs[i].rid, rs[i].flags); + if (res[i] == NULL) { + bus_dwiw_release(dev, rs, res); + return (ENXIO); + } + } + return (0); +} + +void +bus_dwiw_release(device_t dev, struct resource_spec *rs, struct resource **res) +{ + int i; + + for (i = 0; rs[i].type != -1; i++) + if (res[i] != NULL) + bus_release_resource(dev, rs[i].type, rs[i].rid, res[i]); } /* @@ -733,7 +782,7 @@ u_int namelen = arg2; int rman_idx, res_idx; struct rman *rm; - struct resource *res; + struct resource_i *res; struct u_rman urm; struct u_resource ures; int error; Index: pci/if_sis.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_sis.c,v retrieving revision 1.137 diff -u -r1.137 if_sis.c --- pci/if_sis.c 20 Sep 2005 09:52:53 -0000 1.137 +++ pci/if_sis.c 20 Sep 2005 11:00:52 -0000 @@ -107,14 +107,11 @@ /* * register space access macros */ -#define CSR_WRITE_4(sc, reg, val) \ - bus_space_write_4(sc->sis_btag, sc->sis_bhandle, reg, val) +#define CSR_WRITE_4(sc, reg, val) bsw_4(sc->sis_res[0], reg, val) -#define CSR_READ_4(sc, reg) \ - bus_space_read_4(sc->sis_btag, sc->sis_bhandle, reg) +#define CSR_READ_4(sc, reg) bsr_4(sc->sis_res[0], reg) -#define CSR_READ_2(sc, reg) \ - bus_space_read_2(sc->sis_btag, sc->sis_bhandle, reg) +#define CSR_READ_2(sc, reg) bsr_2(sc->sis_res[0], reg) /* * Various supported device vendors/types and their names. @@ -147,6 +144,12 @@ #define SIS_RID SIS_PCI_LOMEM #endif +static struct resource_spec sis_res_spec[] = { + { SIS_RES, SIS_RID}, + { SYS_RES_IRQ, 0}, + { -1, 0 } +}; + #define SIS_SETBIT(sc, reg, x) \ CSR_WRITE_4(sc, reg, \ CSR_READ_4(sc, reg) | (x)) @@ -919,7 +922,7 @@ u_char eaddr[ETHER_ADDR_LEN]; struct sis_softc *sc; struct ifnet *ifp; - int unit, error = 0, rid, waittime = 0; + int unit, error = 0, waittime = 0; waittime = 0; sc = device_get_softc(dev); @@ -943,28 +946,9 @@ */ pci_enable_busmaster(dev); - rid = SIS_RID; - sc->sis_res = bus_alloc_resource_any(dev, SIS_RES, &rid, RF_ACTIVE); - - if (sc->sis_res == NULL) { - printf("sis%d: couldn't map ports/memory\n", unit); - error = ENXIO; - goto fail; - } - - sc->sis_btag = rman_get_bustag(sc->sis_res); - sc->sis_bhandle = rman_get_bushandle(sc->sis_res); - - /* Allocate interrupt */ - rid = 0; - sc->sis_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, - RF_SHAREABLE | RF_ACTIVE); - - if (sc->sis_irq == NULL) { - printf("sis%d: couldn't map interrupt\n", unit); - error = ENXIO; - goto fail; - } + error = bus_dwiw_alloc(dev, sis_res_spec, sc->sis_res); + if (error) + return (error); /* Reset the adapter. */ sis_reset(sc); @@ -1257,7 +1241,7 @@ ifp->if_capenable = ifp->if_capabilities; /* Hook interrupt last to avoid having to lock softc */ - error = bus_setup_intr(dev, sc->sis_irq, INTR_TYPE_NET | INTR_MPSAFE, + error = bus_setup_intr(dev, sc->sis_res[1], INTR_TYPE_NET | INTR_MPSAFE, sis_intr, sc, &sc->sis_intrhand); if (error) { @@ -1304,11 +1288,8 @@ bus_generic_detach(dev); if (sc->sis_intrhand) - bus_teardown_intr(dev, sc->sis_irq, sc->sis_intrhand); - if (sc->sis_irq) - bus_release_resource(dev, SYS_RES_IRQ, 0, sc->sis_irq); - if (sc->sis_res) - bus_release_resource(dev, SIS_RES, SIS_RID, sc->sis_res); + bus_teardown_intr(dev, sc->sis_res[1], sc->sis_intrhand); + bus_dwiw_release(dev, sis_res_spec, sc->sis_res); if (sc->sis_rx_tag) { bus_dmamap_unload(sc->sis_rx_tag, Index: pci/if_sisreg.h =================================================================== RCS file: /home/ncvs/src/sys/pci/if_sisreg.h,v retrieving revision 1.34 diff -u -r1.34 if_sisreg.h --- pci/if_sisreg.h 20 Sep 2005 09:52:53 -0000 1.34 +++ pci/if_sisreg.h 20 Sep 2005 11:00:52 -0000 @@ -431,10 +431,7 @@ struct sis_softc { struct ifnet *sis_ifp; /* interface info */ - bus_space_handle_t sis_bhandle; - bus_space_tag_t sis_btag; - struct resource *sis_res; - struct resource *sis_irq; + struct resource *sis_res[2]; void *sis_intrhand; device_t sis_self; device_t sis_miibus; Index: sparc64/include/bus.h =================================================================== RCS file: /home/ncvs/src/sys/sparc64/include/bus.h,v retrieving revision 1.37 diff -u -r1.37 bus.h --- sparc64/include/bus.h 18 Apr 2005 21:45:34 -0000 1.37 +++ sparc64/include/bus.h 20 Sep 2005 11:00:52 -0000 @@ -220,6 +220,8 @@ return (lduba_nc((caddr_t)(h + o), bus_type_asi[t->bst_type])); } +#define bsr_1(r,o) bus_space_read_1((r)->r_bustag, (r)->r_bushandle, (o)) + static __inline uint16_t bus_space_read_2(bus_space_tag_t t, bus_space_handle_t h, bus_size_t o) { @@ -228,6 +230,8 @@ return (lduha_nc((caddr_t)(h + o), bus_type_asi[t->bst_type])); } +#define bsr_2(r,o) bus_space_read_2((r)->r_bustag, (r)->r_bushandle, (o)) + static __inline uint32_t bus_space_read_4(bus_space_tag_t t, bus_space_handle_t h, bus_size_t o) { @@ -236,6 +240,8 @@ return (lduwa_nc((caddr_t)(h + o), bus_type_asi[t->bst_type])); } +#define bsr_4(r,o) bus_space_read_4((r)->r_bustag, (r)->r_bushandle, (o)) + static __inline uint64_t bus_space_read_8(bus_space_tag_t t, bus_space_handle_t h, bus_size_t o) { @@ -289,6 +295,8 @@ stba_nc((caddr_t)(h + o), bus_type_asi[t->bst_type], v); } +#define bsw_1(r,o,v) bus_space_write_1((r)->r_bustag, (r)->r_bushandle, (o), (v)) + static __inline void bus_space_write_2(bus_space_tag_t t, bus_space_handle_t h, bus_size_t o, uint16_t v) @@ -298,6 +306,8 @@ stha_nc((caddr_t)(h + o), bus_type_asi[t->bst_type], v); } +#define bsw_2(r,o,v) bus_space_write_2((r)->r_bustag, (r)->r_bushandle, (o), (v)) + static __inline void bus_space_write_4(bus_space_tag_t t, bus_space_handle_t h, bus_size_t o, uint32_t v) @@ -307,6 +317,8 @@ stwa_nc((caddr_t)(h + o), bus_type_asi[t->bst_type], v); } +#define bsw_4(r,o,v) bus_space_write_4((r)->r_bustag, (r)->r_bushandle, (o), (v)) + static __inline void bus_space_write_8(bus_space_tag_t t, bus_space_handle_t h, bus_size_t o, uint64_t v) Index: sys/bus.h =================================================================== RCS file: /home/ncvs/src/sys/sys/bus.h,v retrieving revision 1.71 diff -u -r1.71 bus.h --- sys/bus.h 18 Sep 2005 01:32:09 -0000 1.71 +++ sys/bus.h 20 Sep 2005 11:00:52 -0000 @@ -88,7 +88,7 @@ /* * Forward declarations */ -typedef struct device *device_t; +/* typedef struct device *device_t; */ /** * @brief A device driver (included mainly for compatibility with Index: sys/param.h =================================================================== RCS file: /home/ncvs/src/sys/sys/param.h,v retrieving revision 1.248 diff -u -r1.248 param.h --- sys/param.h 25 Aug 2005 19:49:53 -0000 1.248 +++ sys/param.h 20 Sep 2005 11:00:52 -0000 @@ -323,4 +323,8 @@ #define ctodb(db) /* calculates pages to devblks */ \ ((db) << (PAGE_SHIFT - DEV_BSHIFT)) +/* Forward for sys/bus.h */ +struct device; +typedef struct device *device_t; + #endif /* _SYS_PARAM_H_ */ Index: sys/rman.h =================================================================== RCS file: /home/ncvs/src/sys/sys/rman.h,v retrieving revision 1.27 diff -u -r1.27 rman.h --- sys/rman.h 12 Apr 2005 06:21:58 -0000 1.27 +++ sys/rman.h 20 Sep 2005 11:00:52 -0000 @@ -84,6 +84,17 @@ }; #ifdef _KERNEL + +/* + * The public (kernel) view of struct resource + */ + +struct resource { + struct resource_i *__r_i; + bus_space_tag_t r_bustag; /* bus_space tag */ + bus_space_handle_t r_bushandle; /* bus_space handle */ +}; + /* * We use a linked list rather than a bitmap because we need to be able to * represent potentially huge objects (like all of a processor's physical @@ -93,18 +104,17 @@ * at some point in the future, particularly if we want to support 36-bit * addresses on IA32 hardware. */ -TAILQ_HEAD(resource_head, resource); +TAILQ_HEAD(resource_head, resource_i); #ifdef __RMAN_RESOURCE_VISIBLE -struct resource { - TAILQ_ENTRY(resource) r_link; - LIST_ENTRY(resource) r_sharelink; - LIST_HEAD(, resource) *r_sharehead; +struct resource_i { + struct resource r_r; + TAILQ_ENTRY(resource_i) r_link; + LIST_ENTRY(resource_i) r_sharelink; + LIST_HEAD(, resource_i) *r_sharehead; u_long r_start; /* index of the first entry in this resource */ u_long r_end; /* index of the last entry (inclusive) */ u_int r_flags; void *r_virtual; /* virtual address of this resource */ - bus_space_tag_t r_bustag; /* bus_space tag */ - bus_space_handle_t r_bushandle; /* bus_space handle */ struct device *r_dev; /* device which has allocated this resource */ struct rman *r_rm; /* resource manager from whence this came */ void *r_spare1; /* Spare pointer 1 */ @@ -112,7 +122,6 @@ int r_rid; /* optional rid for this resource. */ }; #else -struct resource; struct device; #endif @@ -127,6 +136,15 @@ }; TAILQ_HEAD(rman_head, rman); +struct resource_spec { + int type; + int rid; + int flags; +}; + +void bus_dwiw_release(device_t dev, struct resource_spec *rs, struct resource **res); +int bus_dwiw_alloc(device_t dev, struct resource_spec *rs, struct resource **res); + int rman_activate_resource(struct resource *r); int rman_await_resource(struct resource *r, int pri, int timo); bus_space_handle_t rman_get_bushandle(struct resource *); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 20 14:44:47 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FD2216A41F for ; Tue, 20 Sep 2005 14:44:47 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 201C743D45 for ; Tue, 20 Sep 2005 14:44:47 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 20 Sep 2005 11:00:34 -0400 From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 20 Sep 2005 10:45:58 -0400 User-Agent: KMail/1.8 References: <5975.1127215219@critter.freebsd.dk> In-Reply-To: <5975.1127215219@critter.freebsd.dk> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200509201045.58685.jhb@FreeBSD.org> Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Cc: Poul-Henning Kamp Subject: Re: Improving bus/resource API 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, 20 Sep 2005 14:44:47 -0000 On Tuesday 20 September 2005 07:20 am, Poul-Henning Kamp wrote: > The patch below improves the bus/resource API such that between 10 > and 20 lines of code can be eliminated from the attach/detach > functions of the average device driver. > > Therefore the best place to start is to read what the patch does > to if_sis.c, which is a very typical case. > > The patch is backwards compatible in binary and source form so > it is a potential candidate for RELENG_6 at some point. > > Compile tested on i386/amd64 and sparc64. My alpha will be chewing > on it for the forseeable future. > > > For sanity in the ensuing bikeshed, let's take three topics in > this order: > > 1. "what this does to the device driver sources." > > 2. "what this does to the rman/bus internals" > > 3. "suggestions for different function names" I'll only comment on 3) Maybe bus_read_{1,2,4}() rather than bsr_? (Same with s/bsw_/bus_write_/). I do like having the accessors take just a resource rather than a tag, handle pair. Many drivers already hide this in wrapper macros already though. For the dwiw (dwim? :-P) maybe since it takes an array, just make the 'resource' part plural, thus 'bus_alloc_resources()' and 'bus_release_resources()'? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue Sep 20 15:55:58 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 846B116A41F; Tue, 20 Sep 2005 15:55:58 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4D0443D4C; Tue, 20 Sep 2005 15:55:57 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from [192.168.1.254] (dhcp254.qubesoft.com [192.168.1.254]) by mail.qubesoft.com (8.13.3/8.13.3) with ESMTP id j8KFttB8069467; Tue, 20 Sep 2005 16:55:55 +0100 (BST) (envelope-from dfr@nlsystems.com) In-Reply-To: <200509201045.58685.jhb@FreeBSD.org> References: <5975.1127215219@critter.freebsd.dk> <200509201045.58685.jhb@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76404F68-547C-42E2-A3A9-BD0AF2ECFADF@nlsystems.com> Content-Transfer-Encoding: 7bit From: Doug Rabson Date: Tue, 20 Sep 2005 16:55:54 +0100 To: John Baldwin X-Mailer: Apple Mail (2.734) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.qubesoft.com X-Virus-Scanned: ClamAV 0.86.2/1091/Tue Sep 20 14:59:01 2005 on mail.qubesoft.com X-Virus-Status: Clean Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org Subject: Re: Improving bus/resource API 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, 20 Sep 2005 15:55:58 -0000 On 20 Sep 2005, at 15:45, John Baldwin wrote: > On Tuesday 20 September 2005 07:20 am, Poul-Henning Kamp wrote: > >> The patch below improves the bus/resource API such that between 10 >> and 20 lines of code can be eliminated from the attach/detach >> functions of the average device driver. >> >> Therefore the best place to start is to read what the patch does >> to if_sis.c, which is a very typical case. >> >> The patch is backwards compatible in binary and source form so >> it is a potential candidate for RELENG_6 at some point. >> >> Compile tested on i386/amd64 and sparc64. My alpha will be chewing >> on it for the forseeable future. >> >> >> For sanity in the ensuing bikeshed, let's take three topics in >> this order: >> >> 1. "what this does to the device driver sources." >> >> 2. "what this does to the rman/bus internals" >> >> 3. "suggestions for different function names" >> > > I'll only comment on 3) > > Maybe bus_read_{1,2,4}() rather than bsr_? (Same with s/bsw_/ > bus_write_/). I > do like having the accessors take just a resource rather than a > tag, handle > pair. Many drivers already hide this in wrapper macros already > though. > > For the dwiw (dwim? :-P) maybe since it takes an array, just make the > 'resource' part plural, thus 'bus_alloc_resources()' and > 'bus_release_resources()'? I like these names. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 20 18:58:02 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB3A816A41F for ; Tue, 20 Sep 2005 18:58:02 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5569C43D46 for ; Tue, 20 Sep 2005 18:58:02 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8KIsmqZ040506; Tue, 20 Sep 2005 12:54:49 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 20 Sep 2005 12:55:06 -0600 (MDT) Message-Id: <20050920.125506.102576631.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <5975.1127215219@critter.freebsd.dk> References: <5975.1127215219@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 20 Sep 2005 12:54:49 -0600 (MDT) Cc: arch@freebsd.org Subject: Re: Improving bus/resource API 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, 20 Sep 2005 18:58:03 -0000 First, you need to do s/dwiw/dwim/g. dwiw has little traction, but dwim is an old lisp term. I believe I've said this before. I'd collect the bs{r,w}_{1,2,4,8} routines in a central place. They are all the same #define. Also, there's no provision for the more exotic variations. Bug: There's a disconnect between the resource spec and what you've implemented. You're replaced the normal flags (typically RF_ACTIVE) with non-normal ones (0). You've also encoded the size and offsets of struct resource into every driver. Given the new breakup of this, it might not be too bad. However, that has caused us problems in the past. This is my primary issue with these patches. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Sep 20 19:06:45 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E928316A41F; Tue, 20 Sep 2005 19:06:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F44D43D49; Tue, 20 Sep 2005 19:06:44 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8KJ590F040685; Tue, 20 Sep 2005 13:05:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 20 Sep 2005 13:05:28 -0600 (MDT) Message-Id: <20050920.130528.35014863.imp@bsdimp.com> To: dfr@nlsystems.com From: "M. Warner Losh" In-Reply-To: <76404F68-547C-42E2-A3A9-BD0AF2ECFADF@nlsystems.com> References: <5975.1127215219@critter.freebsd.dk> <200509201045.58685.jhb@FreeBSD.org> <76404F68-547C-42E2-A3A9-BD0AF2ECFADF@nlsystems.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 20 Sep 2005 13:05:11 -0600 (MDT) Cc: phk@phk.freebsd.dk, freebsd-arch@freebsd.org Subject: Re: Improving bus/resource API 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, 20 Sep 2005 19:06:46 -0000 In message: <76404F68-547C-42E2-A3A9-BD0AF2ECFADF@nlsystems.com> Doug Rabson writes: : > Maybe bus_read_{1,2,4}() rather than bsr_? (Same with s/bsw_/ : > bus_write_/). I : > do like having the accessors take just a resource rather than a : > tag, handle : > pair. Many drivers already hide this in wrapper macros already : > though. Are we going to extend this to all the other things that bus space can do? http://people.freebsd.org/~imp/bus_space.html While many of these are less common than the familiar bus_space_{read,write}, we should consider them as part of the updated API. bs vs bus_ vs ???. These are really bus space + resource macros. So maybe we want some other prefix... The whole point of the bsr vs bus_space_read was to make things much shorter. bus_read/write does that, but to a more limited extent. Still, saving 6 characters per function call, plus one argument will help a lot. : > For the dwiw (dwim? :-P) maybe since it takes an array, just make the : > 'resource' part plural, thus 'bus_alloc_resources()' and : > 'bus_release_resources()'? : : I like these names. That would settle the whole dwim vs dwiw arguement :-). I like it. Oh, I found another bug: There are no man pages. This is the only fatal problem. There's still no man page, for example, for the d_*_t functions, nor the cdevsw in general (other than really crunch ones). Warner From owner-freebsd-arch@FreeBSD.ORG Tue Sep 20 20:39:38 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 945CF16A42D for ; Tue, 20 Sep 2005 20:39:38 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71CA543D49 for ; Tue, 20 Sep 2005 20:39:37 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 20 Sep 2005 16:55:25 -0400 From: John Baldwin To: "M. Warner Losh" Date: Tue, 20 Sep 2005 16:08:35 -0400 User-Agent: KMail/1.8 References: <5975.1127215219@critter.freebsd.dk> <76404F68-547C-42E2-A3A9-BD0AF2ECFADF@nlsystems.com> <20050920.130528.35014863.imp@bsdimp.com> In-Reply-To: <20050920.130528.35014863.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509201608.36461.jhb@FreeBSD.org> Cc: phk@phk.freebsd.dk, freebsd-arch@freebsd.org Subject: Re: Improving bus/resource API 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, 20 Sep 2005 20:39:38 -0000 On Tuesday 20 September 2005 03:05 pm, M. Warner Losh wrote: > In message: <76404F68-547C-42E2-A3A9-BD0AF2ECFADF@nlsystems.com> > > Doug Rabson writes: > : > Maybe bus_read_{1,2,4}() rather than bsr_? (Same with s/bsw_/ > : > bus_write_/). I > : > do like having the accessors take just a resource rather than a > : > tag, handle > : > pair. Many drivers already hide this in wrapper macros already > : > though. > > Are we going to extend this to all the other things that bus space can > do? > http://people.freebsd.org/~imp/bus_space.html > > While many of these are less common than the familiar > bus_space_{read,write}, we should consider them as part of the updated > API. > > bs vs bus_ vs ???. These are really bus space + resource macros. So > maybe we want some other prefix... > > The whole point of the bsr vs bus_space_read was to make things much > shorter. bus_read/write does that, but to a more limited extent. > Still, saving 6 characters per function call, plus one argument will > help a lot. I think maybe just do 's/bus_space_/bus_/' on the current names, which gives the simple bus_read/bus_write for the common case. I think that along with reducing the first two args down to one that should make things shorter without making it cryptic. (I think bsrm_4() would be cryptic compared to bus_read_multi_4().) > : > For the dwiw (dwim? :-P) maybe since it takes an array, just make the > : > 'resource' part plural, thus 'bus_alloc_resources()' and > : > 'bus_release_resources()'? > : > : I like these names. > > That would settle the whole dwim vs dwiw arguement :-). I like it. > > Oh, I found another bug: There are no man pages. This is the only > fatal problem. There's still no man page, for example, for the d_*_t > functions, nor the cdevsw in general (other than really crunch ones). Now now, it's just a proposal at this stage. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Sep 21 14:09:45 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19A0C16A41F; Wed, 21 Sep 2005 14:09:45 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABD5243D45; Wed, 21 Sep 2005 14:09:44 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j8LE9hDe007444; Wed, 21 Sep 2005 07:09:43 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j8LE9h1I007443; Wed, 21 Sep 2005 07:09:43 -0700 Date: Wed, 21 Sep 2005 07:09:43 -0700 From: Brooks Davis To: "Matthew N. Dodd" Message-ID: <20050921140943.GB3739@odin.ac.hmc.edu> References: <20050826202713.X1915@sasami.jurai.net> <20050827014153.GA14720@odin.ac.hmc.edu> <20050826221016.B1915@sasami.jurai.net> <20050827170600.GB14720@odin.ac.hmc.edu> <20050828022351.F63789@sasami.jurai.net> <20050908181052.GH31354@odin.ac.hmc.edu> <20050914091957.P56212@sasami.jurai.net> <43293189.5000200@FreeBSD.org> <20050915094948.K79434@sasami.jurai.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc" Content-Disposition: inline In-Reply-To: <20050915094948.K79434@sasami.jurai.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: arch@FreeBSD.ORG, Doug Barton Subject: Re: [CFR] reflect resolv.conf update to running application 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: Wed, 21 Sep 2005 14:09:45 -0000 --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 15, 2005 at 09:59:48AM -0400, Matthew N. Dodd wrote: > On Thu, 15 Sep 2005, Doug Barton wrote: > >Yes, include works, but it runs a similar risk to modifying the=20 > >named.conf file, namely if the syntax of the the statements in the=20 > >include file are not right, loading named.conf will fail. So, we should= =20 > >build some caution into the process of updating the file, but that's=20 > >easily done with the named-checkconf program that comes with the=20 > >distribution. >=20 > I'm not sure such paranoia is needed; dhclient has always exposed the=20 > system to the risk of having an invalid resolv.conf and regenerating the= =20 > named.conf file is no different. Since we're regenerating the included= =20 > file completely I don't see that this is risky at all. The domain name server values will be valid host names. dhclient checks that so we can count on it. I had broken the search checks, but have since fixed that. It might be useful to still write a resolv.conf that only refers to 127.0.0.1 and includes the search directive if we write the forwarder's file. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDMWmlXY6L6fI4GtQRAqNYAJ4z8cXGL57onEUlzreEzOUHH7md0QCfaUK0 KQz7m2YCNoK/iQhHAEzbW9M= =YJjj -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- From owner-freebsd-arch@FreeBSD.ORG Wed Sep 21 15:00:39 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 085E416A41F for ; Wed, 21 Sep 2005 15:00:39 +0000 (GMT) (envelope-from bobhead@frontiernet.net) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.182.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D07A43D7B for ; Wed, 21 Sep 2005 15:00:30 +0000 (GMT) (envelope-from bobhead@frontiernet.net) Received: from filter04.roc.ny.frontiernet.net (filter04.roc.ny.frontiernet.net [66.133.183.71]) by relay03.roc.ny.frontiernet.net (Postfix) with ESMTP id E87CB35854D for ; Wed, 21 Sep 2005 15:00:22 +0000 (UTC) Received: from relay03.roc.ny.frontiernet.net ([66.133.182.166]) by filter04.roc.ny.frontiernet.net (filter04.roc.ny.frontiernet.net [66.133.183.71]) (amavisd-new, port 10024) with LMTP id 03934-02-26 for ; Wed, 21 Sep 2005 15:00:22 +0000 (UTC) Received: from smtp.frontiernet.net (70-96-78-188.dsl1.ado.il.frontiernet.net [70.96.78.188]) by relay03.roc.ny.frontiernet.net (Postfix) with SMTP id EA4213583A3 for ; Wed, 21 Sep 2005 15:00:21 +0000 (UTC) From: "Ron Nelson" Date: Wed, 21 Sep 2005 10:01:21 To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20050921150021.EA4213583A3@relay03.roc.ny.frontiernet.net> X-Virus-Scanned: by amavisd-new-2.3.2 (20050629) at filter04.roc.ny.frontiernet.net Subject: school mascot items 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: Wed, 21 Sep 2005 15:00:39 -0000 Mascot items made to your specifications. Minimum quantity is only 120. Priced for great profits Bobblehead mascots-- Mascot ornaments-- Magnets-- Chain pulls-- Garden stepping stones with school name and logo or mascot-- Special teacher, coach or individual We can probably make any item you can think of at an unbelievably low price. Email us for quotes and questions. rnelson@bobhead.com go here for a details page www.bobhead.com/process.htm Please pass this information on to your sports boosters or anyone interested in mascot items for fund raising. Our online school catalog www.bobhead.com/catalog.htm Nelson Sports Collectibles www.bobhead.com 800 275 3586 From owner-freebsd-arch@FreeBSD.ORG Thu Sep 22 10:24:08 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FA9A16A41F for ; Thu, 22 Sep 2005 10:24:08 +0000 (GMT) (envelope-from fierykylin@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id C53CD43D45 for ; Thu, 22 Sep 2005 10:24:07 +0000 (GMT) (envelope-from fierykylin@gmail.com) Received: by xproxy.gmail.com with SMTP id t14so257045wxc for ; Thu, 22 Sep 2005 03:24:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=GttQuLXX8SACV8subf71ePT5SsFondc6d4b5OgdLa/gAJQAQPCBwv37mjOYZHAuX0C0hQSPRvenOmAY0DqueguWaaWA242jRwPGsJATpZXUWz6l41PbGnpwYWcK51/WFEbV9+Upc2K8f1hPOYhZt6jYN0fPk7Cj2uFabC8M/3pU= Received: by 10.70.87.20 with SMTP id k20mr182286wxb; Thu, 22 Sep 2005 03:24:05 -0700 (PDT) Received: by 10.70.44.11 with HTTP; Thu, 22 Sep 2005 03:24:05 -0700 (PDT) Message-ID: <87ab37ab050922032416304db0@mail.gmail.com> Date: Thu, 22 Sep 2005 18:24:05 +0800 From: kylin To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: freebsd vs K42 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kylin List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 10:24:08 -0000 hello every one : i recently see the k42 system ,which is totally OOP-based,and i also know that freebsd has implement some oop THOUGHT,so, what is the different between the OOP method embed in Freebsd and the one in K42 OO operating system? -- we who r about to die,salute u! From owner-freebsd-arch@FreeBSD.ORG Fri Sep 23 13:56:51 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD3BE16A41F for ; Fri, 23 Sep 2005 13:56:51 +0000 (GMT) (envelope-from tobez@tobez.org) Received: from heechee.tobez.org (heechee.tobez.org [217.157.39.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DACC43D45 for ; Fri, 23 Sep 2005 13:56:50 +0000 (GMT) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id 85CBB125493; Fri, 23 Sep 2005 15:56:49 +0200 (CEST) Date: Fri, 23 Sep 2005 15:56:49 +0200 From: Anton Berezin To: arch@FreeBSD.org Message-ID: <20050923135649.GD25534@heechee.tobez.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Powered-By: FreeBSD http://www.freebsd.org/ User-Agent: Mutt/1.5.10i Cc: Subject: [CFR] Introduce "route del" as a synonym to "route delete" 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, 23 Sep 2005 13:56:51 -0000 Any objections? Index: keywords =================================================================== RCS file: /home/ncvs/src/sbin/route/keywords,v retrieving revision 1.5 diff -u -r1.5 keywords --- keywords 12 Jun 2001 13:31:53 -0000 1.5 +++ keywords 23 Sep 2005 13:21:42 -0000 @@ -6,6 +6,7 @@ blackhole change cloning +del delete dst expire Index: route.8 =================================================================== RCS file: /home/ncvs/src/sbin/route/route.8,v retrieving revision 1.44 diff -u -r1.44 route.8 --- route.8 13 Feb 2005 22:25:16 -0000 1.44 +++ route.8 23 Sep 2005 13:26:10 -0000 @@ -83,13 +83,15 @@ .Pp The .Nm -utility provides six commands: +utility provides seven commands: .Pp .Bl -tag -width Fl -compact .It Cm add Add a route. .It Cm flush Remove all routes. +.It Cm del +Delete a specific route. .It Cm delete Delete a specific route. .It Cm change Index: route.c =================================================================== RCS file: /home/ncvs/src/sbin/route/route.c,v retrieving revision 1.79 diff -u -r1.79 route.c --- route.c 23 May 2005 14:12:32 -0000 1.79 +++ route.c 23 Sep 2005 13:21:50 -0000 @@ -174,6 +174,7 @@ case K_CHANGE: case K_ADD: + case K_DEL: case K_DELETE: newroute(argc, argv); /* NOTREACHED */ -- An undefined problem has an infinite number of solutions. -- Robert A. Humphrey From owner-freebsd-arch@FreeBSD.ORG Fri Sep 23 14:00:23 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5E9116A41F; Fri, 23 Sep 2005 14:00:23 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8099543D45; Fri, 23 Sep 2005 14:00:23 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.52 (FreeBSD)) id 1EIo5q-0001Zi-R0; Fri, 23 Sep 2005 16:00:02 +0200 Date: Fri, 23 Sep 2005 16:00:02 +0200 From: Kirill Ponomarew To: Anton Berezin Message-ID: <20050923140002.GE3797@voodoo.oberon.net> References: <20050923135649.GD25534@heechee.tobez.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050923135649.GD25534@heechee.tobez.org> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE Keywords: 579279786 Cc: arch@FreeBSD.org Subject: Re: [CFR] Introduce "route del" as a synonym to "route delete" 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, 23 Sep 2005 14:00:24 -0000 On Fri, Sep 23, 2005 at 03:56:49PM +0200, Anton Berezin wrote: > Any objections? I missed "del" for route(8) for years in FreeBSD. Actually I'd like to have it. -Kirill From owner-freebsd-arch@FreeBSD.ORG Fri Sep 23 14:01:42 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C048E16A41F; Fri, 23 Sep 2005 14:01:42 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-3-1-cust208.cdif.cable.ntl.com [82.31.78.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 343EA43D45; Fri, 23 Sep 2005 14:01:42 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from setantae by shrike.submonkey.net with local (Exim 4.52 (FreeBSD)) id 1EIo7R-000PWD-3K; Fri, 23 Sep 2005 15:01:41 +0100 Date: Fri, 23 Sep 2005 15:01:41 +0100 From: Ceri Davies To: Anton Berezin Message-ID: <20050923140140.GR72516@submonkey.net> Mail-Followup-To: Ceri Davies , Anton Berezin , arch@FreeBSD.org References: <20050923135649.GD25534@heechee.tobez.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DXIF1lRUlMsbZ3S1" Content-Disposition: inline In-Reply-To: <20050923135649.GD25534@heechee.tobez.org> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.11 Sender: Ceri Davies Cc: arch@FreeBSD.org Subject: Re: [CFR] Introduce "route del" as a synonym to "route delete" 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, 23 Sep 2005 14:01:42 -0000 --DXIF1lRUlMsbZ3S1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 23, 2005 at 03:56:49PM +0200, Anton Berezin wrote: > Any objections? Any benefit? What's the rationale? > --- route.8 13 Feb 2005 22:25:16 -0000 1.44 > +++ route.8 23 Sep 2005 13:26:10 -0000 > @@ -83,13 +83,15 @@ > .Pp > The > .Nm > -utility provides six commands: > +utility provides seven commands: > .Pp > .Bl -tag -width Fl -compact > .It Cm add > Add a route. > .It Cm flush > Remove all routes. > +.It Cm del > +Delete a specific route. That's probably better spelled as "Alias for 'delete'". Ceri --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --DXIF1lRUlMsbZ3S1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDNArEocfcwTS3JF8RAqYxAJ0UqTRlc0WuB1sTpQu4P44T7qWVaQCfW/lm vg9bfpk5kCSJnS6jVHAI5RI= =e56l -----END PGP SIGNATURE----- --DXIF1lRUlMsbZ3S1-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 23 14:05:44 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ADF016A41F for ; Fri, 23 Sep 2005 14:05:44 +0000 (GMT) (envelope-from tobez@tobez.org) Received: from heechee.tobez.org (heechee.tobez.org [217.157.39.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC1E643D45 for ; Fri, 23 Sep 2005 14:05:43 +0000 (GMT) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id D30C8125496; Fri, 23 Sep 2005 16:05:41 +0200 (CEST) Date: Fri, 23 Sep 2005 16:05:41 +0200 From: Anton Berezin To: Ceri Davies , arch@FreeBSD.org Message-ID: <20050923140541.GE25534@heechee.tobez.org> References: <20050923135649.GD25534@heechee.tobez.org> <20050923140140.GR72516@submonkey.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050923140140.GR72516@submonkey.net> X-Powered-By: FreeBSD http://www.freebsd.org/ User-Agent: Mutt/1.5.10i Cc: Subject: Re: [CFR] Introduce "route del" as a synonym to "route delete" 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, 23 Sep 2005 14:05:44 -0000 On Fri, Sep 23, 2005 at 03:01:41PM +0100, Ceri Davies wrote: > On Fri, Sep 23, 2005 at 03:56:49PM +0200, Anton Berezin wrote: > > Any objections? > > Any benefit? What's the rationale? Convenience. > > --- route.8 13 Feb 2005 22:25:16 -0000 1.44 > > +++ route.8 23 Sep 2005 13:26:10 -0000 > > @@ -83,13 +83,15 @@ > > .Pp > > The > > .Nm > > -utility provides six commands: > > +utility provides seven commands: > > .Pp > > .Bl -tag -width Fl -compact > > .It Cm add > > Add a route. > > .It Cm flush > > Remove all routes. > > +.It Cm del > > +Delete a specific route. > > That's probably better spelled as "Alias for 'delete'". Yes, I agree, thanks. \Anton. -- An undefined problem has an infinite number of solutions. -- Robert A. Humphrey From owner-freebsd-arch@FreeBSD.ORG Fri Sep 23 14:10:20 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9601B16A41F; Fri, 23 Sep 2005 14:10:20 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-3-1-cust208.cdif.cable.ntl.com [82.31.78.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02D3F43D64; Fri, 23 Sep 2005 14:10:15 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from setantae by shrike.submonkey.net with local (Exim 4.52 (FreeBSD)) id 1EIoFj-0000Pq-8k; Fri, 23 Sep 2005 15:10:15 +0100 Date: Fri, 23 Sep 2005 15:10:15 +0100 From: Ceri Davies To: Anton Berezin Message-ID: <20050923141015.GS72516@submonkey.net> Mail-Followup-To: Ceri Davies , Anton Berezin , arch@FreeBSD.org References: <20050923135649.GD25534@heechee.tobez.org> <20050923140140.GR72516@submonkey.net> <20050923140541.GE25534@heechee.tobez.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yklP1rR72f9kjNtc" Content-Disposition: inline In-Reply-To: <20050923140541.GE25534@heechee.tobez.org> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.11 Sender: Ceri Davies Cc: arch@FreeBSD.org Subject: Re: [CFR] Introduce "route del" as a synonym to "route delete" 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, 23 Sep 2005 14:10:20 -0000 --yklP1rR72f9kjNtc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 23, 2005 at 04:05:41PM +0200, Anton Berezin wrote: > On Fri, Sep 23, 2005 at 03:01:41PM +0100, Ceri Davies wrote: > > On Fri, Sep 23, 2005 at 03:56:49PM +0200, Anton Berezin wrote: > > > Any objections? > >=20 > > Any benefit? What's the rationale? >=20 > Convenience. I don't get it, though. I have FreeBSD, Solaris and Digital UNIX systems here and none of them support "del". What does? Ceri --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --yklP1rR72f9kjNtc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDNAzHocfcwTS3JF8RAvARAKCEZltbfP9VVQUYtCwwkpBmGLl94QCgscVz 38uo2uCWY4NN7KeEW3IlXPs= =aAdj -----END PGP SIGNATURE----- --yklP1rR72f9kjNtc-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 23 14:13:09 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E54116A41F; Fri, 23 Sep 2005 14:13:09 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10F6743D45; Fri, 23 Sep 2005 14:13:09 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.52 (FreeBSD)) id 1EIoIC-0001e9-5q; Fri, 23 Sep 2005 16:12:48 +0200 Date: Fri, 23 Sep 2005 16:12:48 +0200 From: Kirill Ponomarew To: Ceri Davies , Anton Berezin , arch@FreeBSD.org Message-ID: <20050923141248.GF3797@voodoo.oberon.net> References: <20050923135649.GD25534@heechee.tobez.org> <20050923140140.GR72516@submonkey.net> <20050923140541.GE25534@heechee.tobez.org> <20050923141015.GS72516@submonkey.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050923141015.GS72516@submonkey.net> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE Keywords: 579279786 Cc: Subject: Re: [CFR] Introduce "route del" as a synonym to "route delete" 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, 23 Sep 2005 14:13:09 -0000 On Fri, Sep 23, 2005 at 03:10:15PM +0100, Ceri Davies wrote: > On Fri, Sep 23, 2005 at 04:05:41PM +0200, Anton Berezin wrote: > > On Fri, Sep 23, 2005 at 03:01:41PM +0100, Ceri Davies wrote: > > > On Fri, Sep 23, 2005 at 03:56:49PM +0200, Anton Berezin wrote: > > > > Any objections? > > > > > > Any benefit? What's the rationale? > > > > Convenience. > > I don't get it, though. I have FreeBSD, Solaris and Digital UNIX systems > here and none of them support "del". What does? eg Linux. -Kirill From owner-freebsd-arch@FreeBSD.ORG Fri Sep 23 14:16:25 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05E4316A41F; Fri, 23 Sep 2005 14:16:25 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-3-1-cust208.cdif.cable.ntl.com [82.31.78.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D8DE43D49; Fri, 23 Sep 2005 14:16:24 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from setantae by shrike.submonkey.net with local (Exim 4.52 (FreeBSD)) id 1EIoLf-000GHX-Mp; Fri, 23 Sep 2005 15:16:23 +0100 Date: Fri, 23 Sep 2005 15:16:23 +0100 From: Ceri Davies To: Kirill Ponomarew Message-ID: <20050923141623.GT72516@submonkey.net> Mail-Followup-To: Ceri Davies , Kirill Ponomarew , Anton Berezin , arch@FreeBSD.org References: <20050923135649.GD25534@heechee.tobez.org> <20050923140140.GR72516@submonkey.net> <20050923140541.GE25534@heechee.tobez.org> <20050923141015.GS72516@submonkey.net> <20050923141248.GF3797@voodoo.oberon.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qi3SIpffvxS/TM8d" Content-Disposition: inline In-Reply-To: <20050923141248.GF3797@voodoo.oberon.net> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.11 Sender: Ceri Davies Cc: arch@FreeBSD.org, Anton Berezin Subject: Re: [CFR] Introduce "route del" as a synonym to "route delete" 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, 23 Sep 2005 14:16:25 -0000 --qi3SIpffvxS/TM8d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 23, 2005 at 04:12:48PM +0200, Kirill Ponomarew wrote: > On Fri, Sep 23, 2005 at 03:10:15PM +0100, Ceri Davies wrote: > > On Fri, Sep 23, 2005 at 04:05:41PM +0200, Anton Berezin wrote: > > > On Fri, Sep 23, 2005 at 03:01:41PM +0100, Ceri Davies wrote: > > > > On Fri, Sep 23, 2005 at 03:56:49PM +0200, Anton Berezin wrote: > > > > > Any objections? > > > >=20 > > > > Any benefit? What's the rationale? > > >=20 > > > Convenience. > >=20 > > I don't get it, though. I have FreeBSD, Solaris and Digital UNIX syste= ms > > here and none of them support "del". What does? >=20 > eg Linux. Aha. Well it isn't going to kill me either way, and if it does make life easier that's fair enough, but the old bastard in me wants people to read manuals before they go typing in administrative commands ;) Ceri --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --qi3SIpffvxS/TM8d Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDNA43ocfcwTS3JF8RAiILAKCYkVpM584CyuMiK91VDfek1cB//ACbB9kp NhlQzbvA2EDfhN8e9t+veP0= =t7Xx -----END PGP SIGNATURE----- --qi3SIpffvxS/TM8d-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 23 14:21:29 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00B5716A41F for ; Fri, 23 Sep 2005 14:21:28 +0000 (GMT) (envelope-from massimo@cedoc.mo.it) Received: from insomma.datacode.it (ip-152-166.sn2.eutelia.it [83.211.152.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5478B43D48 for ; Fri, 23 Sep 2005 14:21:27 +0000 (GMT) (envelope-from massimo@cedoc.mo.it) Received: from localhost (localhost.datacode.it [127.0.0.1]) by insomma.datacode.it (Postfix) with SMTP id CF1192C90B for ; Fri, 23 Sep 2005 16:21:24 +0200 (CEST) Received: from insomma.datacode.it (localhost.datacode.it [127.0.0.1]) by insomma.datacode.it (Postfix) with ESMTP id 168712C90A for ; Fri, 23 Sep 2005 16:21:24 +0200 (CEST) Received: from massimo.datacode.it (massimo.datacode.it [192.168.1.13]) by insomma.datacode.it (Postfix) with ESMTP id CB66F2C906 for ; Fri, 23 Sep 2005 16:21:23 +0200 (CEST) From: Massimo Lusetti To: freebsd-arch@freebsd.org In-Reply-To: <20050923141015.GS72516@submonkey.net> References: <20050923135649.GD25534@heechee.tobez.org> <20050923140140.GR72516@submonkey.net> <20050923140541.GE25534@heechee.tobez.org> <20050923141015.GS72516@submonkey.net> Content-Type: text/plain Organization: CEDOC - Modena Date: Fri, 23 Sep 2005 16:21:23 +0200 Message-Id: <1127485283.4307.2.camel@massimo.datacode.it> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [CFR] Introduce "route del" as a synonym to "route delete" 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, 23 Sep 2005 14:21:29 -0000 On Fri, 2005-09-23 at 15:10 +0100, Ceri Davies wrote: > I don't get it, though. I have FreeBSD, Solaris and Digital UNIX systems > here and none of them support "del". What does? Just for the records nor OpenBSD and NetBSD does -- Massimo.run(); From owner-freebsd-arch@FreeBSD.ORG Fri Sep 23 14:33:55 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A43E116A41F for ; Fri, 23 Sep 2005 14:33:55 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B057543D45 for ; Fri, 23 Sep 2005 14:33:54 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 36477 invoked from network); 23 Sep 2005 14:07:29 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Sep 2005 14:07:29 -0000 Message-ID: <43341252.1EAF17AF@freebsd.org> Date: Fri, 23 Sep 2005 16:33:54 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Anton Berezin References: <20050923135649.GD25534@heechee.tobez.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: [CFR] Introduce "route del" as a synonym to "route delete" 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, 23 Sep 2005 14:33:55 -0000 Anton Berezin wrote: > > Any objections? No. Just go ahead and put it in. -- Andre > Index: keywords > =================================================================== > RCS file: /home/ncvs/src/sbin/route/keywords,v > retrieving revision 1.5 > diff -u -r1.5 keywords > --- keywords 12 Jun 2001 13:31:53 -0000 1.5 > +++ keywords 23 Sep 2005 13:21:42 -0000 > @@ -6,6 +6,7 @@ > blackhole > change > cloning > +del > delete > dst > expire > Index: route.8 > =================================================================== > RCS file: /home/ncvs/src/sbin/route/route.8,v > retrieving revision 1.44 > diff -u -r1.44 route.8 > --- route.8 13 Feb 2005 22:25:16 -0000 1.44 > +++ route.8 23 Sep 2005 13:26:10 -0000 > @@ -83,13 +83,15 @@ > .Pp > The > .Nm > -utility provides six commands: > +utility provides seven commands: > .Pp > .Bl -tag -width Fl -compact > .It Cm add > Add a route. > .It Cm flush > Remove all routes. > +.It Cm del > +Delete a specific route. > .It Cm delete > Delete a specific route. > .It Cm change > Index: route.c > =================================================================== > RCS file: /home/ncvs/src/sbin/route/route.c,v > retrieving revision 1.79 > diff -u -r1.79 route.c > --- route.c 23 May 2005 14:12:32 -0000 1.79 > +++ route.c 23 Sep 2005 13:21:50 -0000 > @@ -174,6 +174,7 @@ > > case K_CHANGE: > case K_ADD: > + case K_DEL: > case K_DELETE: > newroute(argc, argv); > /* NOTREACHED */ > > -- > An undefined problem has an infinite number of solutions. > -- Robert A. Humphrey > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Fri Sep 23 20:33:49 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF71216A41F for ; Fri, 23 Sep 2005 20:33:49 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B57543D49 for ; Fri, 23 Sep 2005 20:33:48 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 08568BC66 for ; Fri, 23 Sep 2005 20:33:46 +0000 (UTC) To: freebsd-arch@freebsd.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 20 Sep 2005 16:08:35 EDT." <200509201608.36461.jhb@FreeBSD.org> Date: Fri, 23 Sep 2005 22:33:46 +0200 Message-ID: <59445.1127507626@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: Re: Improving bus/resource API (take 2) 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, 23 Sep 2005 20:33:49 -0000 OK, take two, changes from last: * naming changes adopted. * wrapper macros moved to sys/bus.h, and geneated with a script. The script is not run at compile time, and will go in src/tools/bus_macro.sh, but it is not included in this patch. * device_t typedef in sys/types.h instead of sys/param.h * lost flags in two drivers restored. I do wonder if these flags should not have sensible defaults (RF_ACTIVE for IO/MEM, RF_ACTIVE|RF_SHAREABLE for IRQ ?) * Add comment about why changing struct resource is bad. I would personally still prefer to do a s/bus_read/bus_rd/ s/bus_write/bus_wr/ to slim down the names further, but I can live with this patch. Index: dev/ieee488/tnt4882.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ieee488/tnt4882.c,v retrieving revision 1.1 diff -u -r1.1 tnt4882.c --- dev/ieee488/tnt4882.c 15 Sep 2005 13:27:16 -0000 1.1 +++ dev/ieee488/tnt4882.c 23 Sep 2005 19:35:33 -0000 @@ -51,12 +51,17 @@ int foo; struct upd7210 upd7210; - struct resource *res0, *res1, *res2; - bus_space_tag_t bt0, bt1; - bus_space_handle_t bh0, bh1; + struct resource *res[3]; void *intr_handler; }; +static struct resource_spec tnt_res_spec[] = { + { SYS_RES_MEMORY, PCIR_BAR(0), RF_ACTIVE}, + { SYS_RES_MEMORY, PCIR_BAR(1), RF_ACTIVE}, + { SYS_RES_IRQ, 0, RF_ACTIVE | RF_SHAREABLE}, + { -1, 0 } +}; + enum tnt4882reg { dir = 0x00, cdor = 0x00, @@ -229,10 +234,10 @@ for (step = 0; tp->action != END; tp++, step++) { switch (tp->action) { case WT: - bus_space_write_1(sc->bt1, sc->bh1, tp->reg, tp->val); + bus_write_1(sc->res[1], tp->reg, tp->val); break; case RD: - u = bus_space_read_1(sc->bt1, sc->bh1, tp->reg); + u = bus_read_1(sc->res[1], tp->reg); if (u != tp->val) { printf( "Test %s, step %d: reg(%02x) = %02x", @@ -256,56 +261,6 @@ } static int -bus_dwiw(device_t dev, ...) -{ - va_list ap, ap2; - int rid; - int type; - int flags; - struct resource **rp; - bus_space_tag_t *bt; - bus_space_handle_t *bh; - - va_start(ap, dev); - va_copy(ap2, ap); - while (1) { - type = va_arg(ap, int); - if (type == -1) { - va_end(ap); - return (0); - } - rid = va_arg(ap, int); - flags = va_arg(ap, int); - rp = va_arg(ap, struct resource **); - *rp = bus_alloc_resource_any(dev, type, &rid, flags); - if (*rp == NULL) - break; - if (type == SYS_RES_IOPORT || type == SYS_RES_MEMORY) { - bt = va_arg(ap, bus_space_tag_t *); - *bt = rman_get_bustag(*rp); - bh = va_arg(ap, bus_space_handle_t *); - *bh = rman_get_bushandle(*rp); - } - } - while (1) { - type = va_arg(ap2, int); - KASSERT(type != -1, ("bus_dwiw() internal mess")); - rid = va_arg(ap2, int); - flags = va_arg(ap2, int); - rp = va_arg(ap2, struct resource **); - if (*rp != NULL) - bus_release_resource(dev, type, rid, *rp); - else { - va_end(ap2); - return (ENXIO); - } - if (type == SYS_RES_IOPORT || type == SYS_RES_MEMORY) { - bt = va_arg(ap2, bus_space_tag_t *); - bh = va_arg(ap2, bus_space_handle_t *); - } - } -} -static int tnt_probe(device_t dev) { @@ -324,21 +279,15 @@ sc = device_get_softc(dev); - error = bus_dwiw(dev, - SYS_RES_MEMORY, PCIR_BAR(0), RF_ACTIVE, - &sc->res0, &sc->bt0, &sc->bh0, - SYS_RES_MEMORY, PCIR_BAR(1), RF_ACTIVE, - &sc->res1, &sc->bt1, &sc->bh1, - SYS_RES_IRQ, 0, RF_ACTIVE | RF_SHAREABLE, &sc->res2, - -1); + error = bus_alloc_resources(dev, tnt_res_spec, sc->res); if (error) return (error); - error = bus_setup_intr(dev, sc->res2, INTR_TYPE_MISC | INTR_MPSAFE, + error = bus_setup_intr(dev, sc->res[2], INTR_TYPE_MISC | INTR_MPSAFE, upd7210intr, &sc->upd7210, &sc->intr_handler); /* Necessary magic for MITE */ - bus_space_write_4(sc->bt0, sc->bh0, 0xc0, vtophys(sc->bh1) | 0x80); + bus_write_4(sc->res[0], 0xc0, rman_get_start(sc->res[1]) | 0x80); tst_exec(sc, tst_reset, "Reset"); tst_exec(sc, tst_read_reg, "Read registers"); @@ -350,11 +299,11 @@ tst_exec(sc, tst_reset, "Reset"); /* pass 7210 interrupts through */ - bus_space_write_1(sc->bt1, sc->bh1, imr3, 0x02); + bus_write_1(sc->res[1], imr3, 0x02); for (i = 0; i < 8; i++) { - sc->upd7210.reg_tag[i] = sc->bt1; - sc->upd7210.reg_handle[i] = sc->bh1; + sc->upd7210.reg_tag[i] = rman_get_bustag(sc->res[1]); + sc->upd7210.reg_handle[i] = rman_get_bushandle(sc->res[1]); sc->upd7210.reg_offset[i] = i * 2; } @@ -372,12 +321,10 @@ struct tnt_softc *sc; sc = device_get_softc(dev); - bus_teardown_intr(dev, sc->res2, sc->intr_handler); + bus_teardown_intr(dev, sc->res[2], sc->intr_handler); upd7210detach(&sc->upd7210); - bus_release_resource(dev, SYS_RES_MEMORY, PCIR_BAR(0), sc->res0); - bus_release_resource(dev, SYS_RES_MEMORY, PCIR_BAR(1), sc->res1); - bus_release_resource(dev, SYS_RES_IRQ, 0, sc->res2); + bus_release_resources(dev, tnt_res_spec, sc->res); return (0); } Index: kern/subr_rman.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_rman.c,v retrieving revision 1.43 diff -u -r1.43 subr_rman.c --- kern/subr_rman.c 6 May 2005 02:48:20 -0000 1.43 +++ kern/subr_rman.c 23 Sep 2005 19:46:43 -0000 @@ -81,10 +81,22 @@ struct rman_head rman_head; static struct mtx rman_mtx; /* mutex to protect rman_head */ -static int int_rman_activate_resource(struct rman *rm, struct resource *r, - struct resource **whohas); -static int int_rman_deactivate_resource(struct resource *r); -static int int_rman_release_resource(struct rman *rm, struct resource *r); +static int int_rman_activate_resource(struct rman *rm, struct resource_i *r, + struct resource_i **whohas); +static int int_rman_deactivate_resource(struct resource_i *r); +static int int_rman_release_resource(struct rman *rm, struct resource_i *r); + +static __inline struct resource_i * +int_alloc_resource(int malloc_flag) +{ + struct resource_i *r; + + r = malloc(sizeof *r, M_RMAN, malloc_flag | M_ZERO); + if (r != NULL) { + r->r_r.__r_i = r; + } + return (r); +} int rman_init(struct rman *rm) @@ -121,11 +133,11 @@ int rman_manage_region(struct rman *rm, u_long start, u_long end) { - struct resource *r, *s; + struct resource_i *r, *s; DPRINTF(("rman_manage_region: <%s> request: start %#lx, end %#lx\n", rm->rm_descr, start, end)); - r = malloc(sizeof *r, M_RMAN, M_NOWAIT | M_ZERO); + r = int_alloc_resource(M_NOWAIT); if (r == 0) return ENOMEM; r->r_start = start; @@ -151,7 +163,7 @@ int rman_fini(struct rman *rm) { - struct resource *r; + struct resource_i *r; mtx_lock(rm->rm_mtx); TAILQ_FOREACH(r, &rm->rm_list, r_link) { @@ -186,7 +198,7 @@ struct device *dev) { u_int want_activate; - struct resource *r, *s, *rv; + struct resource_i *r, *s, *rv; u_long rstart, rend, amask, bmask; rv = 0; @@ -267,7 +279,7 @@ * split it in two. The first case requires * two new allocations; the second requires but one. */ - rv = malloc(sizeof *rv, M_RMAN, M_NOWAIT | M_ZERO); + rv = int_alloc_resource(M_NOWAIT); if (rv == 0) goto out; rv->r_start = rstart; @@ -285,7 +297,7 @@ /* * We are allocating in the middle. */ - r = malloc(sizeof *r, M_RMAN, M_NOWAIT|M_ZERO); + r = int_alloc_resource(M_NOWAIT); if (r == 0) { free(rv, M_RMAN); rv = 0; @@ -343,7 +355,7 @@ && (s->r_end - s->r_start + 1) == count && (s->r_start & amask) == 0 && ((s->r_start ^ s->r_end) & bmask) == 0) { - rv = malloc(sizeof *rv, M_RMAN, M_NOWAIT | M_ZERO); + rv = int_alloc_resource(M_NOWAIT); if (rv == 0) goto out; rv->r_start = s->r_start; @@ -383,7 +395,7 @@ * make sense for RF_TIMESHARE-type resources.) */ if (rv && want_activate) { - struct resource *whohas; + struct resource_i *whohas; if (int_rman_activate_resource(rm, rv, &whohas)) { int_rman_release_resource(rm, rv); rv = 0; @@ -391,7 +403,7 @@ } mtx_unlock(rm->rm_mtx); - return (rv); + return (&rv->r_r); } struct resource * @@ -404,10 +416,10 @@ } static int -int_rman_activate_resource(struct rman *rm, struct resource *r, - struct resource **whohas) +int_rman_activate_resource(struct rman *rm, struct resource_i *r, + struct resource_i **whohas) { - struct resource *s; + struct resource_i *s; int ok; /* @@ -439,12 +451,13 @@ } int -rman_activate_resource(struct resource *r) +rman_activate_resource(struct resource *re) { int rv; - struct resource *whohas; + struct resource_i *r, *whohas; struct rman *rm; + r = re->__r_i; rm = r->r_rm; mtx_lock(rm->rm_mtx); rv = int_rman_activate_resource(rm, r, &whohas); @@ -453,12 +466,13 @@ } int -rman_await_resource(struct resource *r, int pri, int timo) +rman_await_resource(struct resource *re, int pri, int timo) { int rv; - struct resource *whohas; + struct resource_i *r, *whohas; struct rman *rm; + r = re->__r_i; rm = r->r_rm; mtx_lock(rm->rm_mtx); for (;;) { @@ -478,7 +492,7 @@ } static int -int_rman_deactivate_resource(struct resource *r) +int_rman_deactivate_resource(struct resource_i *r) { r->r_flags &= ~RF_ACTIVE; @@ -494,17 +508,17 @@ { struct rman *rm; - rm = r->r_rm; + rm = r->__r_i->r_rm; mtx_lock(rm->rm_mtx); - int_rman_deactivate_resource(r); + int_rman_deactivate_resource(r->__r_i); mtx_unlock(rm->rm_mtx); return 0; } static int -int_rman_release_resource(struct rman *rm, struct resource *r) +int_rman_release_resource(struct rman *rm, struct resource_i *r) { - struct resource *s, *t; + struct resource_i *s, *t; if (r->r_flags & RF_ACTIVE) int_rman_deactivate_resource(r); @@ -595,11 +609,14 @@ } int -rman_release_resource(struct resource *r) +rman_release_resource(struct resource *re) { int rv; - struct rman *rm = r->r_rm; + struct resource_i *r; + struct rman *rm; + r = re->__r_i; + rm = r->r_rm; mtx_lock(rm->rm_mtx); rv = int_rman_release_resource(rm, r); mtx_unlock(rm->rm_mtx); @@ -627,37 +644,37 @@ u_long rman_get_start(struct resource *r) { - return (r->r_start); + return (r->__r_i->r_start); } u_long rman_get_end(struct resource *r) { - return (r->r_end); + return (r->__r_i->r_end); } u_long rman_get_size(struct resource *r) { - return (r->r_end - r->r_start + 1); + return (r->__r_i->r_end - r->__r_i->r_start + 1); } u_int rman_get_flags(struct resource *r) { - return (r->r_flags); + return (r->__r_i->r_flags); } void rman_set_virtual(struct resource *r, void *v) { - r->r_virtual = v; + r->__r_i->r_virtual = v; } void * rman_get_virtual(struct resource *r) { - return (r->r_virtual); + return (r->__r_i->r_virtual); } void @@ -687,37 +704,69 @@ void rman_set_rid(struct resource *r, int rid) { - r->r_rid = rid; + r->__r_i->r_rid = rid; } void rman_set_start(struct resource *r, u_long start) { - r->r_start = start; + r->__r_i->r_start = start; } void rman_set_end(struct resource *r, u_long end) { - r->r_end = end; + r->__r_i->r_end = end; } int rman_get_rid(struct resource *r) { - return (r->r_rid); + return (r->__r_i->r_rid); } struct device * rman_get_device(struct resource *r) { - return (r->r_dev); + return (r->__r_i->r_dev); } void rman_set_device(struct resource *r, struct device *dev) { - r->r_dev = dev; + r->__r_i->r_dev = dev; +} + +/* + * Device driver convenience functions + */ + +int +bus_alloc_resources(device_t dev, struct resource_spec *rs, struct resource **res) +{ + int i; + + for (i = 0; rs[i].type != -1; i++) + res[i] = NULL; + for (i = 0; rs[i].type != -1; i++) { + res[i] = bus_alloc_resource_any(dev, + rs[i].type, &rs[i].rid, rs[i].flags); + if (res[i] == NULL) { + bus_release_resources(dev, rs, res); + return (ENXIO); + } + } + return (0); +} + +void +bus_release_resources(device_t dev, struct resource_spec *rs, struct resource **res) +{ + int i; + + for (i = 0; rs[i].type != -1; i++) + if (res[i] != NULL) + bus_release_resource(dev, rs[i].type, rs[i].rid, res[i]); } /* @@ -733,7 +782,7 @@ u_int namelen = arg2; int rman_idx, res_idx; struct rman *rm; - struct resource *res; + struct resource_i *res; struct u_rman urm; struct u_resource ures; int error; Index: pci/if_sis.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_sis.c,v retrieving revision 1.137 diff -u -r1.137 if_sis.c --- pci/if_sis.c 20 Sep 2005 09:52:53 -0000 1.137 +++ pci/if_sis.c 23 Sep 2005 19:28:49 -0000 @@ -107,14 +107,11 @@ /* * register space access macros */ -#define CSR_WRITE_4(sc, reg, val) \ - bus_space_write_4(sc->sis_btag, sc->sis_bhandle, reg, val) +#define CSR_WRITE_4(sc, reg, val) bus_write_4(sc->sis_res[0], reg, val) -#define CSR_READ_4(sc, reg) \ - bus_space_read_4(sc->sis_btag, sc->sis_bhandle, reg) +#define CSR_READ_4(sc, reg) bus_read_4(sc->sis_res[0], reg) -#define CSR_READ_2(sc, reg) \ - bus_space_read_2(sc->sis_btag, sc->sis_bhandle, reg) +#define CSR_READ_2(sc, reg) bus_read_2(sc->sis_res[0], reg) /* * Various supported device vendors/types and their names. @@ -147,6 +144,12 @@ #define SIS_RID SIS_PCI_LOMEM #endif +static struct resource_spec sis_res_spec[] = { + { SIS_RES, SIS_RID, RF_ACTIVE}, + { SYS_RES_IRQ, 0, RF_ACTIVE | RF_SHAREABLE}, + { -1, 0 } +}; + #define SIS_SETBIT(sc, reg, x) \ CSR_WRITE_4(sc, reg, \ CSR_READ_4(sc, reg) | (x)) @@ -919,7 +922,7 @@ u_char eaddr[ETHER_ADDR_LEN]; struct sis_softc *sc; struct ifnet *ifp; - int unit, error = 0, rid, waittime = 0; + int unit, error = 0, waittime = 0; waittime = 0; sc = device_get_softc(dev); @@ -943,28 +946,9 @@ */ pci_enable_busmaster(dev); - rid = SIS_RID; - sc->sis_res = bus_alloc_resource_any(dev, SIS_RES, &rid, RF_ACTIVE); - - if (sc->sis_res == NULL) { - printf("sis%d: couldn't map ports/memory\n", unit); - error = ENXIO; - goto fail; - } - - sc->sis_btag = rman_get_bustag(sc->sis_res); - sc->sis_bhandle = rman_get_bushandle(sc->sis_res); - - /* Allocate interrupt */ - rid = 0; - sc->sis_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, - RF_SHAREABLE | RF_ACTIVE); - - if (sc->sis_irq == NULL) { - printf("sis%d: couldn't map interrupt\n", unit); - error = ENXIO; - goto fail; - } + error = bus_alloc_resources(dev, sis_res_spec, sc->sis_res); + if (error) + return (error); /* Reset the adapter. */ sis_reset(sc); @@ -1257,7 +1241,7 @@ ifp->if_capenable = ifp->if_capabilities; /* Hook interrupt last to avoid having to lock softc */ - error = bus_setup_intr(dev, sc->sis_irq, INTR_TYPE_NET | INTR_MPSAFE, + error = bus_setup_intr(dev, sc->sis_res[1], INTR_TYPE_NET | INTR_MPSAFE, sis_intr, sc, &sc->sis_intrhand); if (error) { @@ -1304,11 +1288,9 @@ bus_generic_detach(dev); if (sc->sis_intrhand) - bus_teardown_intr(dev, sc->sis_irq, sc->sis_intrhand); - if (sc->sis_irq) - bus_release_resource(dev, SYS_RES_IRQ, 0, sc->sis_irq); - if (sc->sis_res) - bus_release_resource(dev, SIS_RES, SIS_RID, sc->sis_res); + bus_teardown_intr(dev, sc->sis_res[1], sc->sis_intrhand); + + bus_release_resources(dev, sis_res_spec, sc->sis_res); if (sc->sis_rx_tag) { bus_dmamap_unload(sc->sis_rx_tag, Index: pci/if_sisreg.h =================================================================== RCS file: /home/ncvs/src/sys/pci/if_sisreg.h,v retrieving revision 1.34 diff -u -r1.34 if_sisreg.h --- pci/if_sisreg.h 20 Sep 2005 09:52:53 -0000 1.34 +++ pci/if_sisreg.h 20 Sep 2005 11:00:52 -0000 @@ -431,10 +431,7 @@ struct sis_softc { struct ifnet *sis_ifp; /* interface info */ - bus_space_handle_t sis_bhandle; - bus_space_tag_t sis_btag; - struct resource *sis_res; - struct resource *sis_irq; + struct resource *sis_res[2]; void *sis_intrhand; device_t sis_self; device_t sis_miibus; Index: sys/bus.h =================================================================== RCS file: /home/ncvs/src/sys/sys/bus.h,v retrieving revision 1.71 diff -u -r1.71 bus.h --- sys/bus.h 18 Sep 2005 01:32:09 -0000 1.71 +++ sys/bus.h 23 Sep 2005 19:56:19 -0000 @@ -85,11 +85,6 @@ const char *__type, const char *__data); void devctl_queue_data(char *__data); -/* - * Forward declarations - */ -typedef struct device *device_t; - /** * @brief A device driver (included mainly for compatibility with * FreeBSD 4.x). @@ -294,6 +289,16 @@ * Wrapper functions for the BUS_*_RESOURCE methods to make client code * a little simpler. */ + +struct resource_spec { + int type; + int rid; + int flags; +}; + +int bus_alloc_resources(device_t dev, struct resource_spec *rs, struct resource **res); +void bus_release_resources(device_t dev, struct resource_spec *rs, struct resource **res); + struct resource *bus_alloc_resource(device_t dev, int type, int *rid, u_long start, u_long end, u_long count, u_int flags); @@ -514,6 +519,141 @@ ivarp ## _IVAR_ ## ivar, v); \ } +/** + * Shorthand macros, taking resource argument + * Generated with sys/tools/bus_macro.sh + */ + +#define bus_barrier(r, o, l, f) \ + bus_space_barrier((r)->r_bustag, (r)->r_bushandle, (o), (l), (f)) +#define bus_read_1(r, o) \ + bus_space_read_1((r)->r_bustag, (r)->r_bushandle, (o)) +#define bus_read_multi_1(r, o, d, c) \ + bus_space_read_multi_1((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_region_1(r, o, d, c) \ + bus_space_read_region_1((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_set_multi_1(r, o, v, c) \ + bus_space_set_multi_1((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_set_region_1(r, o, v, c) \ + bus_space_set_region_1((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_write_1(r, o, v) \ + bus_space_write_1((r)->r_bustag, (r)->r_bushandle, (o), (v)) +#define bus_write_multi_1(r, o, d, c) \ + bus_space_write_multi_1((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_write_region_1(r, o, d, c) \ + bus_space_write_region_1((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_stream_1(r, o) \ + bus_space_read_stream_1((r)->r_bustag, (r)->r_bushandle, (o)) +#define bus_read_multi_stream_1(r, o, d, c) \ + bus_space_read_multi_stream_1((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_region_stream_1(r, o, d, c) \ + bus_space_read_region_stream_1((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_set_multi_stream_1(r, o, v, c) \ + bus_space_set_multi_stream_1((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_set_region_stream_1(r, o, v, c) \ + bus_space_set_region_stream_1((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_write_stream_1(r, o, v) \ + bus_space_write_stream_1((r)->r_bustag, (r)->r_bushandle, (o), (v)) +#define bus_write_multi_stream_1(r, o, d, c) \ + bus_space_write_multi_stream_1((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_write_region_stream_1(r, o, d, c) \ + bus_space_write_region_stream_1((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_2(r, o) \ + bus_space_read_2((r)->r_bustag, (r)->r_bushandle, (o)) +#define bus_read_multi_2(r, o, d, c) \ + bus_space_read_multi_2((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_region_2(r, o, d, c) \ + bus_space_read_region_2((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_set_multi_2(r, o, v, c) \ + bus_space_set_multi_2((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_set_region_2(r, o, v, c) \ + bus_space_set_region_2((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_write_2(r, o, v) \ + bus_space_write_2((r)->r_bustag, (r)->r_bushandle, (o), (v)) +#define bus_write_multi_2(r, o, d, c) \ + bus_space_write_multi_2((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_write_region_2(r, o, d, c) \ + bus_space_write_region_2((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_stream_2(r, o) \ + bus_space_read_stream_2((r)->r_bustag, (r)->r_bushandle, (o)) +#define bus_read_multi_stream_2(r, o, d, c) \ + bus_space_read_multi_stream_2((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_region_stream_2(r, o, d, c) \ + bus_space_read_region_stream_2((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_set_multi_stream_2(r, o, v, c) \ + bus_space_set_multi_stream_2((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_set_region_stream_2(r, o, v, c) \ + bus_space_set_region_stream_2((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_write_stream_2(r, o, v) \ + bus_space_write_stream_2((r)->r_bustag, (r)->r_bushandle, (o), (v)) +#define bus_write_multi_stream_2(r, o, d, c) \ + bus_space_write_multi_stream_2((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_write_region_stream_2(r, o, d, c) \ + bus_space_write_region_stream_2((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_4(r, o) \ + bus_space_read_4((r)->r_bustag, (r)->r_bushandle, (o)) +#define bus_read_multi_4(r, o, d, c) \ + bus_space_read_multi_4((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_region_4(r, o, d, c) \ + bus_space_read_region_4((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_set_multi_4(r, o, v, c) \ + bus_space_set_multi_4((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_set_region_4(r, o, v, c) \ + bus_space_set_region_4((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_write_4(r, o, v) \ + bus_space_write_4((r)->r_bustag, (r)->r_bushandle, (o), (v)) +#define bus_write_multi_4(r, o, d, c) \ + bus_space_write_multi_4((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_write_region_4(r, o, d, c) \ + bus_space_write_region_4((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_stream_4(r, o) \ + bus_space_read_stream_4((r)->r_bustag, (r)->r_bushandle, (o)) +#define bus_read_multi_stream_4(r, o, d, c) \ + bus_space_read_multi_stream_4((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_region_stream_4(r, o, d, c) \ + bus_space_read_region_stream_4((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_set_multi_stream_4(r, o, v, c) \ + bus_space_set_multi_stream_4((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_set_region_stream_4(r, o, v, c) \ + bus_space_set_region_stream_4((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_write_stream_4(r, o, v) \ + bus_space_write_stream_4((r)->r_bustag, (r)->r_bushandle, (o), (v)) +#define bus_write_multi_stream_4(r, o, d, c) \ + bus_space_write_multi_stream_4((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_write_region_stream_4(r, o, d, c) \ + bus_space_write_region_stream_4((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_8(r, o) \ + bus_space_read_8((r)->r_bustag, (r)->r_bushandle, (o)) +#define bus_read_multi_8(r, o, d, c) \ + bus_space_read_multi_8((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_region_8(r, o, d, c) \ + bus_space_read_region_8((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_set_multi_8(r, o, v, c) \ + bus_space_set_multi_8((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_set_region_8(r, o, v, c) \ + bus_space_set_region_8((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_write_8(r, o, v) \ + bus_space_write_8((r)->r_bustag, (r)->r_bushandle, (o), (v)) +#define bus_write_multi_8(r, o, d, c) \ + bus_space_write_multi_8((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_write_region_8(r, o, d, c) \ + bus_space_write_region_8((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_stream_8(r, o) \ + bus_space_read_stream_8((r)->r_bustag, (r)->r_bushandle, (o)) +#define bus_read_multi_stream_8(r, o, d, c) \ + bus_space_read_multi_stream_8((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_read_region_stream_8(r, o, d, c) \ + bus_space_read_region_stream_8((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_set_multi_stream_8(r, o, v, c) \ + bus_space_set_multi_stream_8((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_set_region_stream_8(r, o, v, c) \ + bus_space_set_region_stream_8((r)->r_bustag, (r)->r_bushandle, (o), (v), (c)) +#define bus_write_stream_8(r, o, v) \ + bus_space_write_stream_8((r)->r_bustag, (r)->r_bushandle, (o), (v)) +#define bus_write_multi_stream_8(r, o, d, c) \ + bus_space_write_multi_stream_8((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) +#define bus_write_region_stream_8(r, o, d, c) \ + bus_space_write_region_stream_8((r)->r_bustag, (r)->r_bushandle, (o), (d), (c)) #endif /* _KERNEL */ #endif /* !_SYS_BUS_H_ */ Index: sys/rman.h =================================================================== RCS file: /home/ncvs/src/sys/sys/rman.h,v retrieving revision 1.27 diff -u -r1.27 rman.h --- sys/rman.h 12 Apr 2005 06:21:58 -0000 1.27 +++ sys/rman.h 23 Sep 2005 19:43:22 -0000 @@ -84,6 +84,21 @@ }; #ifdef _KERNEL + +/* + * The public (kernel) view of struct resource + * + * NB: Changing the offset/size/type of existing fields in struct resource + * NB: breaks the device driver ABI and is strongly FORBIDDEN. + * NB: Appending new fields is probably just misguided. + */ + +struct resource { + struct resource_i *__r_i; + bus_space_tag_t r_bustag; /* bus_space tag */ + bus_space_handle_t r_bushandle; /* bus_space handle */ +}; + /* * We use a linked list rather than a bitmap because we need to be able to * represent potentially huge objects (like all of a processor's physical @@ -93,18 +108,17 @@ * at some point in the future, particularly if we want to support 36-bit * addresses on IA32 hardware. */ -TAILQ_HEAD(resource_head, resource); +TAILQ_HEAD(resource_head, resource_i); #ifdef __RMAN_RESOURCE_VISIBLE -struct resource { - TAILQ_ENTRY(resource) r_link; - LIST_ENTRY(resource) r_sharelink; - LIST_HEAD(, resource) *r_sharehead; +struct resource_i { + struct resource r_r; + TAILQ_ENTRY(resource_i) r_link; + LIST_ENTRY(resource_i) r_sharelink; + LIST_HEAD(, resource_i) *r_sharehead; u_long r_start; /* index of the first entry in this resource */ u_long r_end; /* index of the last entry (inclusive) */ u_int r_flags; void *r_virtual; /* virtual address of this resource */ - bus_space_tag_t r_bustag; /* bus_space tag */ - bus_space_handle_t r_bushandle; /* bus_space handle */ struct device *r_dev; /* device which has allocated this resource */ struct rman *r_rm; /* resource manager from whence this came */ void *r_spare1; /* Spare pointer 1 */ @@ -112,7 +126,6 @@ int r_rid; /* optional rid for this resource. */ }; #else -struct resource; struct device; #endif Index: sys/types.h =================================================================== RCS file: /home/ncvs/src/sys/sys/types.h,v retrieving revision 1.92 diff -u -r1.92 types.h --- sys/types.h 31 May 2005 15:18:17 -0000 1.92 +++ sys/types.h 23 Sep 2005 18:43:39 -0000 @@ -285,6 +285,8 @@ typedef __uintfptr_t uintfptr_t; typedef __uint64_t uoff_t; typedef struct vm_page *vm_page_t; +typedef struct device *device_t; + #define offsetof(type, field) __offsetof(type, field) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Sep 23 21:29:53 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69A4A16A420 for ; Fri, 23 Sep 2005 21:29:53 +0000 (GMT) (envelope-from squeals@kyrknatet.se) Received: from chb63.neoplus.adsl.tpnet.pl (chb63.neoplus.adsl.tpnet.pl [83.30.255.63]) by mx1.FreeBSD.org (Postfix) with SMTP id A5BB143D5C for ; Fri, 23 Sep 2005 21:29:44 +0000 (GMT) (envelope-from squeals@kyrknatet.se) Received: from 95.137.68.131 (EHLO alumni) by chb63.neoplus.adsl.tpnet.pl with SMTP; Fri, 23 Sep 2005 23:29:33 +0200 id 5435417792anchoritism63114 for freebsd-arch@freebsd.org; Fri, 23 Sep 2005 23:29:33 +0200 Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <5099413890.88380130072@chb63.neoplus.adsl.tpnet.pl> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-arch@freebsd.org From: Margie Date: Fri, 23 Sep 2005 23:29:32 +0200 X-Mailer: Apple Mail (2.728) Subject: Send the love home with an online photo album 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, 23 Sep 2005 21:29:53 -0000 Software suites. http://cguu.uszci10iid02ucu7zuu7hucc.bultowmifd.com/?narn Nunc scio quit sit amor(Now I know what love is) Do well and you will have no need for ancestors. Anyone who truly loves God travels securely. Justice Marshall has made his decision. Let him enforce it. Nothing feeds upon itself as liberality does. Nobody cares if you can't dance well. Just get up and dance. From owner-freebsd-arch@FreeBSD.ORG Sat Sep 24 13:25:09 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DADD816A41F for ; Sat, 24 Sep 2005 13:25:09 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B05F43D49 for ; Sat, 24 Sep 2005 13:25:09 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3CCB1.dip.t-dialin.net [84.163.204.177] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML21M-1EJA1b47op-0000Sx; Sat, 24 Sep 2005 15:25:07 +0200 From: Max Laier To: freebsd-arch@freebsd.org Date: Sat, 24 Sep 2005 15:25:06 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1793368.0b6zZriJF6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509241525.16173.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Subject: Bridges 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, 24 Sep 2005 13:25:10 -0000 --nextPart1793368.0b6zZriJF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, for some time now, we have three bridge implementations in the tree: - net/bridge.c - the "old" bridge - net/if_bridge.c - the "new" bridge from Net/OpenBSD - netgraph/ng_bridge.c - the netgraph version [1] The new code has several advantages over the old version: - Spanning Tree Protocol (802.1D) - better firewall support (IPv6, stateful filtering, ...) - easy ifconfig(8) configuration while keeping all the functionality that was present in the old code: - dummynet support - IPFW L2 support [2] There have been some benchmarks that suggest that there isn't a performance= =20 issue either, but more numbers are always appreciated. If it turns out tha= t=20 there is any remaining problem with if_bridge we need to fix it. If you ar= e=20 running an old bridge on 6.0-BETA try moving to the new code and let us kno= w. This means the old code is obsolete. In order to keep code duplication dow= n=20 and not hinder further development (Andre is working on an overhaul of [2]= =20 and would have to do it twice, for example) I would like to retire the old= =20 bridge code soon. This should happen in HEAD only and thus the old bridge= =20 will stay for all of FreeBSD 6 unless more aggressive depreciation is=20 requested. Please test the new alternative if you are using the old one still. Let us= =20 know if there are any issues remaining. Objections against soon retirement of bridge.c in HEAD? [1] listed for completeness only. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1793368.0b6zZriJF6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDNVO8XyyEoT62BG0RAngdAJ0TYDX2e3yp00PGIx85WB76v17xhQCbB4DJ CNULYoLCB1N8CAzbPamb9WY= =xG7U -----END PGP SIGNATURE----- --nextPart1793368.0b6zZriJF6-- From owner-freebsd-arch@FreeBSD.ORG Sat Sep 24 13:28:27 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1531916A41F for ; Sat, 24 Sep 2005 13:28:27 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB73C43D4C for ; Sat, 24 Sep 2005 13:28:26 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j8ODSQcW051563; Sat, 24 Sep 2005 06:28:26 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j8ODSQsA051562; Sat, 24 Sep 2005 06:28:26 -0700 (PDT) (envelope-from rizzo) Date: Sat, 24 Sep 2005 06:28:26 -0700 From: Luigi Rizzo To: Max Laier Message-ID: <20050924062826.F50725@xorpc.icir.org> References: <200509241525.16173.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200509241525.16173.max@love2party.net>; from max@love2party.net on Sat, Sep 24, 2005 at 03:25:06PM +0200 Cc: freebsd-arch@freebsd.org Subject: Re: Bridges 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, 24 Sep 2005 13:28:27 -0000 i am happy with retiring net/bridge.c in HEAD. cheers luigi On Sat, Sep 24, 2005 at 03:25:06PM +0200, Max Laier wrote: > All, > > for some time now, we have three bridge implementations in the tree: > - net/bridge.c - the "old" bridge > - net/if_bridge.c - the "new" bridge from Net/OpenBSD > - netgraph/ng_bridge.c - the netgraph version [1] > > The new code has several advantages over the old version: > - Spanning Tree Protocol (802.1D) > - better firewall support (IPv6, stateful filtering, ...) > - easy ifconfig(8) configuration > > while keeping all the functionality that was present in the old code: > - dummynet support > - IPFW L2 support [2] > > There have been some benchmarks that suggest that there isn't a performance > issue either, but more numbers are always appreciated. If it turns out that > there is any remaining problem with if_bridge we need to fix it. If you are > running an old bridge on 6.0-BETA try moving to the new code and let us know. > > This means the old code is obsolete. In order to keep code duplication down > and not hinder further development (Andre is working on an overhaul of [2] > and would have to do it twice, for example) I would like to retire the old > bridge code soon. This should happen in HEAD only and thus the old bridge > will stay for all of FreeBSD 6 unless more aggressive depreciation is > requested. > > Please test the new alternative if you are using the old one still. Let us > know if there are any issues remaining. > > Objections against soon retirement of bridge.c in HEAD? > > [1] listed for completeness only. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-arch@FreeBSD.ORG Sat Sep 24 13:35:22 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 600F116A41F for ; Sat, 24 Sep 2005 13:35:22 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: from useful.dataloss.nl (useful.dataloss.nl [80.84.249.161]) by mx1.FreeBSD.org (Postfix) with SMTP id AACFF43D49 for ; Sat, 24 Sep 2005 13:35:21 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: (qmail 38801 invoked by uid 1001); 24 Sep 2005 13:35:19 -0000 Date: Sat, 24 Sep 2005 15:35:19 +0200 From: Peter van Dijk To: freebsd-arch@freebsd.org Message-ID: <20050924133519.GI17888@dataloss.nl> References: <200509241525.16173.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CEUtFxTsmBsHRLs3" Content-Disposition: inline In-Reply-To: <200509241525.16173.max@love2party.net> User-Agent: Mutt/1.4i Subject: Re: Bridges 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, 24 Sep 2005 13:35:22 -0000 --CEUtFxTsmBsHRLs3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 24, 2005 at 03:25:06PM +0200, Max Laier wrote: > Objections against soon retirement of bridge.c in HEAD? One argument in favour of retirement: last time I checked (FreeBSD 6.0-BETA2 I think), bridge.ko is a recipe for instant panic on sparc64. Although now I wonder whether the same is still true for ng_bridge. I'm a happy if_bridge user now :) Cheers, Peter --=20 peter@dataloss.nl | ~ tonight tonight, what is this potion http://blog.dataloss.nl/ | ~ that makes a fool of me UnderNet/#clue | Wayfinder, fr-025 soundtrack --CEUtFxTsmBsHRLs3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFDNVYV7JEU4tMwuvwRArZXAKDI1gxe/1ks1BQFXBFDG7GfI0HmQQCfQILo 40PERn0Q0HkT9le0QXlbkGo= =G6Sj -----END PGP SIGNATURE----- --CEUtFxTsmBsHRLs3-- From owner-freebsd-arch@FreeBSD.ORG Sat Sep 24 14:47:32 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93A0616A41F for ; Sat, 24 Sep 2005 14:47:32 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD2E843D49 for ; Sat, 24 Sep 2005 14:47:31 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 44819 invoked from network); 24 Sep 2005 14:20:55 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Sep 2005 14:20:55 -0000 Message-ID: <43356702.6B558B4A@freebsd.org> Date: Sat, 24 Sep 2005 16:47:30 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Max Laier References: <200509241525.16173.max@love2party.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Bridges 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, 24 Sep 2005 14:47:32 -0000 Max Laier wrote: > > All, > > for some time now, we have three bridge implementations in the tree: > - net/bridge.c - the "old" bridge > - net/if_bridge.c - the "new" bridge from Net/OpenBSD > - netgraph/ng_bridge.c - the netgraph version [1] > > The new code has several advantages over the old version: > - Spanning Tree Protocol (802.1D) > - better firewall support (IPv6, stateful filtering, ...) > - easy ifconfig(8) configuration > > while keeping all the functionality that was present in the old code: > - dummynet support > - IPFW L2 support [2] > > There have been some benchmarks that suggest that there isn't a performance > issue either, but more numbers are always appreciated. If it turns out that > there is any remaining problem with if_bridge we need to fix it. If you are > running an old bridge on 6.0-BETA try moving to the new code and let us know. > > This means the old code is obsolete. In order to keep code duplication down > and not hinder further development (Andre is working on an overhaul of [2] > and would have to do it twice, for example) I would like to retire the old > bridge code soon. This should happen in HEAD only and thus the old bridge > will stay for all of FreeBSD 6 unless more aggressive depreciation is > requested. > > Please test the new alternative if you are using the old one still. Let us > know if there are any issues remaining. > > Objections against soon retirement of bridge.c in HEAD? No objection. if_bridge has surpassed net/bridge.c in features. There is no compelling reason to carry two bridge implementations forward. It only creates a unnecessary maintenance burden. -- Andre From owner-freebsd-arch@FreeBSD.ORG Sat Sep 24 15:34:39 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EAE816A41F for ; Sat, 24 Sep 2005 15:34:39 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B60D43D49 for ; Sat, 24 Sep 2005 15:34:32 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j8OFYUnl074237; Sat, 24 Sep 2005 09:34:30 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <43357207.7080405@samsco.org> Date: Sat, 24 Sep 2005 09:34:31 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <200509241525.16173.max@love2party.net> In-Reply-To: <200509241525.16173.max@love2party.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-arch@freebsd.org Subject: Re: Bridges 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, 24 Sep 2005 15:34:39 -0000 Max Laier wrote: > All, > > for some time now, we have three bridge implementations in the tree: > - net/bridge.c - the "old" bridge > - net/if_bridge.c - the "new" bridge from Net/OpenBSD > - netgraph/ng_bridge.c - the netgraph version [1] > > The new code has several advantages over the old version: > - Spanning Tree Protocol (802.1D) > - better firewall support (IPv6, stateful filtering, ...) > - easy ifconfig(8) configuration > > while keeping all the functionality that was present in the old code: > - dummynet support > - IPFW L2 support [2] > > There have been some benchmarks that suggest that there isn't a performance > issue either, but more numbers are always appreciated. If it turns out that > there is any remaining problem with if_bridge we need to fix it. If you are > running an old bridge on 6.0-BETA try moving to the new code and let us know. > > This means the old code is obsolete. In order to keep code duplication down > and not hinder further development (Andre is working on an overhaul of [2] > and would have to do it twice, for example) I would like to retire the old > bridge code soon. This should happen in HEAD only and thus the old bridge > will stay for all of FreeBSD 6 unless more aggressive depreciation is > requested. > > Please test the new alternative if you are using the old one still. Let us > know if there are any issues remaining. > > Objections against soon retirement of bridge.c in HEAD? > > [1] listed for completeness only. > I'm fine with it being removed in HEAD. You should change the docs and whatever appropriate manpages in 6-STABLE to clearly indicate that it is deprecated there and may be removed in the future. Scott From owner-freebsd-arch@FreeBSD.ORG Sat Sep 24 19:22:42 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 197CB16A41F for ; Sat, 24 Sep 2005 19:22:42 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74E6243D49 for ; Sat, 24 Sep 2005 19:22:41 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail17.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j8OJMcqq021479 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 25 Sep 2005 05:22:39 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j8OJMcSR066111; Sun, 25 Sep 2005 05:22:38 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j8OJMcAQ066110; Sun, 25 Sep 2005 05:22:38 +1000 (EST) (envelope-from pjeremy) Date: Sun, 25 Sep 2005 05:22:38 +1000 From: Peter Jeremy To: Max Laier Message-ID: <20050924192237.GP40237@cirb503493.alcatel.com.au> References: <200509241525.16173.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509241525.16173.max@love2party.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arch@freebsd.org Subject: Re: Bridges 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, 24 Sep 2005 19:22:42 -0000 On Sat, 2005-Sep-24 15:25:06 +0200, Max Laier wrote: >for some time now, we have three bridge implementations in the tree: > - net/bridge.c - the "old" bridge > - net/if_bridge.c - the "new" bridge from Net/OpenBSD > - netgraph/ng_bridge.c - the netgraph version [1] > >The new code has several advantages over the old version: > - Spanning Tree Protocol (802.1D) > - better firewall support (IPv6, stateful filtering, ...) > - easy ifconfig(8) configuration Since I've recently needed it, neither bridge.c nor if_bridge.c allow you to bridge VLAN trunks (you can bridge individual VLANs but that becomes unwieldly when you have dozens of VLANs). I have code to do this in bridge.c. >and would have to do it twice, for example) I would like to retire the old >bridge code soon. This should happen in HEAD only and thus the old bridge >will stay for all of FreeBSD 6 unless more aggressive depreciation is >requested. Since if_bridge.c does not exist in FreeBSD 5, and there has not previously been any suggestion that bridge.c is deprecated, I would object to the removal of bridge.c from FreeBSD 6 since this would violate the standard deprecation cycle. >Please test the new alternative if you are using the old one still. Has anyone looked at how difficult it would be to get if_bridge.c to work in 5.x? -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Sat Sep 24 20:38:57 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED79B16A41F; Sat, 24 Sep 2005 20:38:57 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5697B43D48; Sat, 24 Sep 2005 20:38:57 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3D7BC.dip.t-dialin.net [84.163.215.188] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwpI-1EJGnP482S-0006m5; Sat, 24 Sep 2005 22:38:55 +0200 From: Max Laier To: freebsd-arch@freebsd.org Date: Sat, 24 Sep 2005 22:38:36 +0200 User-Agent: KMail/1.8.2 References: <200509241525.16173.max@love2party.net> <20050924192237.GP40237@cirb503493.alcatel.com.au> In-Reply-To: <20050924192237.GP40237@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1683708.da5CxqY0eD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509242238.51966.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Peter Jeremy , Andrew Thompson Subject: Re: Bridges 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, 24 Sep 2005 20:38:58 -0000 --nextPart1683708.da5CxqY0eD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 24 September 2005 21:22, Peter Jeremy wrote: > On Sat, 2005-Sep-24 15:25:06 +0200, Max Laier wrote: > >for some time now, we have three bridge implementations in the tree: > > - net/bridge.c - the "old" bridge > > - net/if_bridge.c - the "new" bridge from Net/OpenBSD > > - netgraph/ng_bridge.c - the netgraph version [1] > > > >The new code has several advantages over the old version: > > - Spanning Tree Protocol (802.1D) > > - better firewall support (IPv6, stateful filtering, ...) > > - easy ifconfig(8) configuration > > Since I've recently needed it, neither bridge.c nor if_bridge.c allow > you to bridge VLAN trunks (you can bridge individual VLANs but that > becomes unwieldly when you have dozens of VLANs). I have code to do > this in bridge.c. Not sure what you mean, but I am sure Andrew Thompson is willing to help=20 converting your code to if_bridge if asked. BTW, forgot about one big plus= =20 for if_bridge: It is the one true bridge implementation in Net/OpenBSD so=20 there is a lot of additional "developer power" behind it. Of course one=20 could argue that code monoculture is a bad thing ... I like to believe=20 otherwise, however. > >and would have to do it twice, for example) I would like to retire the o= ld > >bridge code soon. This should happen in HEAD only and thus the old brid= ge > >will stay for all of FreeBSD 6 unless more aggressive depreciation is > >requested. > > Since if_bridge.c does not exist in FreeBSD 5, and there has not > previously been any suggestion that bridge.c is deprecated, I would > object to the removal of bridge.c from FreeBSD 6 since this would > violate the standard deprecation cycle. No idea what the standard deprecation cycle is, but no problem. I just wan= t=20 it out of HEAD to be able to move forward with other projects more easily,= =20 such as what Andre is going to do. > >Please test the new alternative if you are using the old one still. > > Has anyone looked at how difficult it would be to get if_bridge.c to > work in 5.x? See http://people.freebsd.org/~thompsa/ for patches. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1683708.da5CxqY0eD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDNblbXyyEoT62BG0RAqhFAJ0Y+7Af7FNteJl2DNvmhK6+1MAFhACdEseY TLDXdLARln397htteZbsip8= =1Mlg -----END PGP SIGNATURE----- --nextPart1683708.da5CxqY0eD--