Re: small tun(4) improvement
On Thu, Oct 14, 2004 at 10:48:32PM +0200, Andre Oppermann wrote: A> > We are going to have triple cut'n'paste: if_tun.c, ng_device.c, if_tap.c. A> > What about m_uiocopy()? The question is where can we put this function? A> A> What about the existing m_uiotombuf() function in kern/uipc_mbuf.c? Damn, I'm blind. :) Investigated libmchain, but missed this. A> > P.P.S. BTW, ng_eiface+ng_device is going to supersede tap(4), same way as A> > ng_iface+ng_device is going to supersede tun(4). :) A> A> Yes and no. While the netgraph equivalents may have the same functionality A> we want to keep the existing and well-known API's to keep porting easier. A> On top of that there is nothing wrong with tap(4) and tun(4) (except the A> mbuf inefficiency you are about to fix). I didn't meant that we will remove tun(4) and tap(4). I meant that we can patch their consumers to alternatively use ng_iface. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: small tun(4) improvement
On Thu, Oct 14, 2004 at 04:23:42PM -0700, Julian Elischer wrote: J> yes I know, that's how we wrote divert.. (to be independent) netgraph J> came later.. J> I guess we would have done divert differently if we had done netgraph J> first.. J> probably would have given ipfw a "hook" command that sent J> packets out a netfgaph hook to whatever was attached.. hmm that could J> still be really usefull... I have a snap code doing this. I have temporarily abandoned that node because, I can't imagine a way to put packets back to ipfw. ipfw is a function, which processes packet and returns. netgraph may queue packets. How can it inject them back into ipfw, so that 1) it is checked from the next rule, not first 2) it will be returned to ip_(input|output) ? J> a netgraph NAT module anyone? In far plans. First we need to solve the above problem with ifpw and netgraph interaction. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[PATCH] Make em(4) use device sysctl tree
Here is a non-critical patch to bring em(4) into line with other
drivers, by using the sysctl tree created for each device by the
bus framework.
Please review; Thanks.
BMS
Index: if_em.c
===
RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.44.2.1
diff -u -p -r1.44.2.1 if_em.c
--- if_em.c 1 Oct 2004 18:51:11 - 1.44.2.1
+++ if_em.c 15 Oct 2004 22:16:05 -
@@ -310,26 +310,14 @@ em_attach(device_t dev)
em_adapter_list = adapter;
/* SYSCTL stuff */
-sysctl_ctx_init(&adapter->sysctl_ctx);
-adapter->sysctl_tree = SYSCTL_ADD_NODE(&adapter->sysctl_ctx,
- SYSCTL_STATIC_CHILDREN(_hw),
- OID_AUTO,
- device_get_nameunit(dev),
- CTLFLAG_RD,
- 0, "");
-if (adapter->sysctl_tree == NULL) {
-error = EIO;
-goto err_sysctl;
-}
-
-SYSCTL_ADD_PROC(&adapter->sysctl_ctx,
-SYSCTL_CHILDREN(adapter->sysctl_tree),
+SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),
+SYSCTL_CHILDREN(device_get_sysctl_tree(dev)),
OID_AUTO, "debug_info", CTLTYPE_INT|CTLFLAG_RW,
(void *)adapter, 0,
em_sysctl_debug_info, "I", "Debug Information");
-SYSCTL_ADD_PROC(&adapter->sysctl_ctx,
-SYSCTL_CHILDREN(adapter->sysctl_tree),
+SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),
+SYSCTL_CHILDREN(device_get_sysctl_tree(dev)),
OID_AUTO, "stats", CTLTYPE_INT|CTLFLAG_RW,
(void *)adapter, 0,
em_sysctl_stats, "I", "Statistics");
@@ -504,8 +492,6 @@ err_rx_desc:
err_tx_desc:
err_pci:
em_free_pci_resources(adapter);
-sysctl_ctx_free(&adapter->sysctl_ctx);
-err_sysctl:
return(error);
}
@@ -553,9 +539,6 @@ em_detach(device_t dev)
adapter->rx_desc_base = NULL;
}
- /* Free the sysctl tree */
- sysctl_ctx_free(&adapter->sysctl_ctx);
-
/* Remove from the adapter list */
if (em_adapter_list == adapter)
em_adapter_list = adapter->next;
@@ -3347,8 +3330,8 @@ em_add_int_delay_sysctl(struct adapter *
info->adapter = adapter;
info->offset = offset;
info->value = value;
- SYSCTL_ADD_PROC(&adapter->sysctl_ctx,
- SYSCTL_CHILDREN(adapter->sysctl_tree),
+ SYSCTL_ADD_PROC(device_get_sysctl_ctx(adapter->dev),
+ SYSCTL_CHILDREN(device_get_sysctl_tree(adapter->dev)),
OID_AUTO, name, CTLTYPE_INT|CTLFLAG_RW,
info, 0, em_sysctl_int_delay, "I", description);
}
pgp4DaMBGnjfs.pgp
Description: PGP signature
Re: small tun(4) improvement
On Thu, Oct 14, 2004 at 09:42:25PM +0400, Gleb Smirnoff wrote: > any objections about commiting this improvement to tun(4)? Optimal use of mbuf clusters to improve performance is cool. Please consider committing this once reworked to use m_uiotombuf. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Make em(4) use device sysctl tree
Bruce M Simpson wrote: > Here is a non-critical patch to bring em(4) into line with other > drivers, by using the sysctl tree created for each device by the > bus framework. > > Please review; Thanks. > BMS [patch ripped] Looks good to me. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Make em(4) use device sysctl tree
Bruce M Simpson wrote: Here is a non-critical patch to bring em(4) into line with other drivers, by using the sysctl tree created for each device by the bus framework. Does anyone here have an idea why some platforms (like Thinkpad X31 or i875 Supermicros) have trouble rebooting with 5.3-BETA when em is used as a module (they hang at "shutting down ACPI") while with 5.2.1-REL the same scenario works fine? Pete Please review; Thanks. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
