Re: [RFC] removing broken includes
On Thu Feb 3 11, Alexander Best wrote:
> hi everybody,
>
> i've started to check the source for broken includes, such as the one fixed in
> r218189. so far i've run through arch=amd64 and found only two broken
> includes,
> which should be fixed by the attached patch. the commands i'm using are:
>
> for target=buildkernel:
> make SRCCONF=/dev/null __MAKE_CONF=/dev/null NO_WARNS= CWARNFLAGS="-w -Werror
> -Wmissing-include-dirs" buildkernel
>
> for target=buildworld:[*]
> make SRCCONF=/dev/null __MAKE_CONF=/dev/null WITHOUT_CDDL=true NO_WARNS=
> CWARNFLAGS="-w -Wmissing-include-dirs" buildworld
>
> next up are the other archs. also i'll try to run both buildworld and
> installworld with "CC=clang -v" and "CXX=clang++ -v". although clang turns
> -Wmissing-include-dirs into a noop, using the -v flag one can still detect
> broken (and even duplicate) includes. thanks to pluknet@ for the info.
with the patch i submitted in the previous message arch=i386 reported no extra
broken dirs.
i'll put the other archs on hold, until this thread triggers more attention. no
point in dedicating more time, if nothing comes out of it. ;)
cheers.
alex
>
> cheers.
> alex
>
> [*] the reason i'm setting WITHOUT_CDDL=true is that my installed world was
> compiled with that option. trying to buildworld with CDDL support thus fails.
> also at first i was trying to use the same command for buildworld, as i used
> for buildkernel. however it seems CWARNFLAGS gets set in some places, so
> gcc(1)
> will also treat non -Wmissing-include-dirs warnings as errors.
>
> --
> a13x
> Index: sys/conf/files
> ===
> --- sys/conf/files(revision 218217)
> +++ sys/conf/files(working copy)
> @@ -960,7 +960,7 @@
> dev/e1000/e1000_82571.c optional em | igb \
> compile-with "${NORMAL_C} -I$S/dev/e1000"
> dev/e1000/e1000_82575.c optional em | igb \
> - compile-with "${NORMAL_C} -I$S/dev/igb"
> + compile-with "${NORMAL_C} -I$S/dev/e1000"
> dev/e1000/e1000_ich8lan.coptional em | igb \
> compile-with "${NORMAL_C} -I$S/dev/e1000"
> dev/e1000/e1000_api.coptional em | igb \
> Index: sys/modules/netgraph/atm/ccatm/Makefile
> ===
> --- sys/modules/netgraph/atm/ccatm/Makefile (revision 218217)
> +++ sys/modules/netgraph/atm/ccatm/Makefile (working copy)
> @@ -12,6 +12,6 @@
> SRCS=ng_ccatm.c cc_conn.c cc_data.c cc_dump.c cc_port.c cc_sig.c
> \
> cc_user.c unisap.c
>
> -CFLAGS+= -I${LIBBASE} -I${LIBBASE}/netnatm/ccatm -DCCATM_DEBUG
> +CFLAGS+= -I${LIBBASE} -DCCATM_DEBUG
>
> .include
--
a13x
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Replacing a failed disk in raidz2 zfs (and gpt)
On 02/03/2011 06:11, Philip M. Gollucci wrote: > I can't for the life of me get zpool to replace it. I can't remember why > I used gpt instead of direct disks for the zmysql pool (but thats how it > is). ISTR you had to online a drive first, then issue the replace command. Also, it could be you used GPT to offset your ZFS partition on a 4 Kibyte boundary, because your drive might be one of those "hey I'm a 4 Kibyte physical sector size drive but I'll claim to have a 512 byte sector size, both logical and physical, just to annoy you!" drives. That's why I don't use raw disks for my ZFS drives, anyway. Cheers, -- Thomas E. Spanjaard t...@netphreax.net t...@deepbone.net signature.asc Description: OpenPGP digital signature
Re: [RFC] removing broken includes
On Thursday, February 03, 2011 5:12:57 pm Alexander Best wrote: > hi everybody, > > i've started to check the source for broken includes, such as the one fixed in > r218189. so far i've run through arch=amd64 and found only two broken > includes, > which should be fixed by the attached patch. the commands i'm using are: The sys/conf/files fix should definitely go in. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] removing broken includes
On Fri Feb 4 11, John Baldwin wrote: > On Thursday, February 03, 2011 5:12:57 pm Alexander Best wrote: > > hi everybody, > > > > i've started to check the source for broken includes, such as the one fixed > > in > > r218189. so far i've run through arch=amd64 and found only two broken > > includes, > > which should be fixed by the attached patch. the commands i'm using are: > > The sys/conf/files fix should definitely go in. thanks for the comment. since i don't have src commit rights: please anybody feel free to commit the patch or parts of it. cheers. alex > > -- > John Baldwin -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH] OpenSolaris/ZFS: C++ compatibility
The attached patch is sufficient to allow a C++ program to use libzfs.
The motivation for these changes is work I'm doing on a ZFS fault
handling daemon that is written in C++. SpectraLogic's intention
is to return this work to the FreeBSD project once it is a bit more
complete.
Since these changes modify files that come from OpenSolaris, I want to be
sure I understand the project's policies regarding divergence from
the vendor before I check them in. All of the changes save one should
be trivial to merge with vendor changes and I will do that work for the
v28 import. Is there any reason I should not commit these changes?
Thanks,
Justin
Change 477353 by justing@justing-ns1 on 2011/02/04 10:11:30
Remove C constructs that are incompatible with C++ from various
OpenSolaris and ZFS header files. These changes are sufficient
to allow a C++ program to use the libzfs library.
Note: The majority of these files already included 'extern "C"'
declarations, so the intention of providing C++ compatibility
already existed even if it wasn't provided.
cddl/compat/opensolaris/include/assert.h:
Wrap our compatibility assert implementation in
'extern "C"'. Since this is a compatibility header
I matched the Solaris style of doing this explicitly
rather than rely on FreeBSD's __BEGIN/END_DECLS macro.
sys/cddl/compat/opensolaris/sys/kstat.h:
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h:
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa.h:
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h:
Place comments around parameters in function declarations
that conflict with C++ keywords.
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_ioctl.h:
In C, nested structures are visible in the global namespace,
but in C++, they take on the namespace of the structure in
which they are contained. Flatten nested structure
definitions within struct zfs_cmd so these structures are
visible in the global namespace when compiled in both
languages.
Affected files ...
... //depot/SpectraBSD/head/cddl/compat/opensolaris/include/assert.h#4 edit
... //depot/SpectraBSD/head/sys/cddl/compat/opensolaris/sys/kstat.h#4 edit
...
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h#4
edit
...
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa.h#4
edit
...
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_ioctl.h#4
edit
...
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h#6
edit
Differences ...
//depot/SpectraBSD/head/cddl/compat/opensolaris/include/assert.h#4 (text)
@@ -43,6 +43,10 @@
#include
#include
+#ifdef __cplusplus
+extern "C" {
+#endif
+
static __inline void
__assert(const char *expr, const char *file, int line)
{
@@ -52,4 +56,9 @@
abort();
/* NOTREACHED */
}
+
+#ifdef __cplusplus
+}
+#endif
+
#endif /* !_ASSERT_H_ */
//depot/SpectraBSD/head/sys/cddl/compat/opensolaris/sys/kstat.h#4 (text)
@@ -58,7 +58,7 @@
} value;
} kstat_named_t;
-kstat_t *kstat_create(char *module, int instance, char *name, char *class,
+kstat_t *kstat_create(char *module, int instance, char *name, char */*class*/,
uchar_t type, ulong_t ndata, uchar_t flags);
void kstat_install(kstat_t *ksp);
void kstat_delete(kstat_t *ksp);
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h#4
(text)
@@ -131,7 +131,7 @@
void dsl_pool_memory_pressure(dsl_pool_t *dp);
void dsl_pool_willuse_space(dsl_pool_t *dp, int64_t space, dmu_tx_t *tx);
int dsl_free(zio_t *pio, dsl_pool_t *dp, uint64_t txg, const blkptr_t *bpp,
-zio_done_func_t *done, void *private, uint32_t arc_flags);
+zio_done_func_t *done, void */*private*/, uint32_t arc_flags);
void dsl_pool_ds_destroyed(struct dsl_dataset *ds, struct dmu_tx *tx);
void dsl_pool_ds_snapshotted(struct dsl_dataset *ds, struct dmu_tx *tx);
void dsl_pool_ds_clone_swapped(struct dsl_dataset *ds1, struct dsl_dataset
*ds2,
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa.h#4
(text)
@@ -511,7 +511,7 @@
struct zbookmark;
struct zio;
extern void spa_log_error(spa_t *spa, struct zio *zio);
-extern void zfs_ereport_post(const char *class, spa_t *spa, vdev_t *vd,
+extern void zfs_ereport_post(const char */*class*/, spa_t *spa, vdev_t *vd,
struct zio *zio, uint64_t stateoroffset, uint64_t length);
extern void zfs_post_remove(spa_t *spa, vdev_t *vd);
extern void zfs_post_autoreplace(spa_t *spa, vdev_t *vd);
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sy
Re: [RFC] removing broken includes
On Fri Feb 4 11, John Baldwin wrote:
> On Thursday, February 03, 2011 5:12:57 pm Alexander Best wrote:
> > hi everybody,
> >
> > i've started to check the source for broken includes, such as the one fixed
> > in
> > r218189. so far i've run through arch=amd64 and found only two broken
> > includes,
> > which should be fixed by the attached patch. the commands i'm using are:
>
> The sys/conf/files fix should definitely go in.
as a side note: while checking the tinderbox output i saw a few gas related
warnings, which complained about VCS IDs being spammed to object files.
the following patch should take care of those cases (at least for archs amd64
and i386).
also i noticed a lot of these warnings:
usr/subversion-src/lib/libc/i386/string/memcpy.S:7: Warning: ignoring incorrect
section type for .note.GNU-stack
i think i've seen some recent commits dealing with that new section.
cheers.
alex
>
> --
> John Baldwin
--
a13x
Index: sbin/routed/rtquery/rtquery.c
===
--- sbin/routed/rtquery/rtquery.c (revision 218217)
+++ sbin/routed/rtquery/rtquery.c (working copy)
@@ -49,6 +49,7 @@
#include
#endif
+#if 0
#define UNUSED __attribute__((unused))
#ifndef __RCSID
#define __RCSID(_s) static const char rcsid[] UNUSED = _s
@@ -67,6 +68,7 @@
__RCSID("$Revision: 2.26 $");
#ident "$Revision: 2.26 $"
#endif
+#endif
#ifndef sgi
#define _HAVE_SIN_LEN
Index: contrib/lukemftp/src/main.c
===
--- contrib/lukemftp/src/main.c (revision 218217)
+++ contrib/lukemftp/src/main.c (working copy)
@@ -96,8 +96,10 @@
#include
#ifndef lint
+#if 0
__COPYRIGHT("@(#) Copyright (c) 1985, 1989, 1993, 1994\n\
The Regents of the University of California. All rights reserved.\n");
+#endif
#endif /* not lint */
#ifndef lint
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ethernet Drivers: Question on Sending Received Packets to the FreeBSD Network Stack
On Thu, 3 Feb 2011, Julian Elischer wrote: On 2/3/11 10:08 AM, David Somayajulu wrote: Hi All, While sending the Received Ethernet Frames (non - LRO case) to the FreeBSD Network Stack via (struct ifnet *)->if_input((struct ifnet *), (struct *mbuf)); Is it possible to send multiple Ethernet Frames in a single invocation of the above callback function? In other words should (struct *mbuf) above always correspond to a single Ethernet Frame? I am not sure if I missed something, but I gathered from a quick perusal of ether_input() in net/if_ethersubr.c, that only ONE Ethernet Frame may be sent per callback. yes only one. the linkages you see in the mbuf definition are for when you are putting it into some queue (interface, socket, reassembly, etc). I had never considered passing a set of packets, but after my initial scoffing thoughts I realized that it would actually be a very interesting thought experiment to see if the ability to do that would be advantageous in any way. I tmay be a way to reduce some sorts of overhead if using interrupt mitigation. This was discussed quite a lot at the network-related devsummit sessions a few years ago. One idea that was bandied about was introducing an mbuf vector data structure (I'm sure at least two floated around in Perforce at some point, and another ended up built into the Chelsio driver I think). The idea being that indirection through queues as with mbufs is quite inefficient when you want to pass them around in sets when the set may not be in the cache. Instead, vectors of mbuf pointers would be passed around, each entry being a chain representing a packet. I think one reason that idea never really went anywhere was that the use cases were fairly artificial for anything other than link layer bridging between exactly two interfaces or systems with exactly one high-volume TCP connection. In most scenarios, packets may come in small bursts going to the same destination (etc), as is exploited by LRO, but not in a way that you're able to maintain passing around in sets that remain viable as you get above the link layer. I seem to recall benchmarking one of the prototypes and finding that it increased the working set on memory noticeably since it effectively meant much more queueing was taking place, whereas our current direct dispatch model helped latency a great deal. It could be that with more deferred dispatch in a parallel setting, it helps, but you'd definitely want to take a measurement-oriented approach in looking at it any further. (For bridged ethernet filtering devices that act as a "bump in the wire", it might well prove a reasonable performance optimisation. I'm not sure if the cxgb mvec implementation would be appropriate to this task or not.) Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ethernet Drivers: Question on Sending Received Packets to the FreeBSD Network Stack
On 2/3/11 4:25 PM, Ryan Stone wrote: On Thu, Feb 3, 2011 at 2:48 PM, Julian Elischer wrote: I had never considered passing a set of packets, but after my initial scoffing thoughts I realized that it would actually be a very interesting thought experiment to see if the ability to do that would be advantageous in any way. I tmay be a way to reduce some sorts of overhead if using interrupt mitigation. At $WORK we've put a rather considerable amount of effort into writing what I'd call a poor-man's version of netgraph. Originally, in fact, our application was entirely netgraph-based back when we were running on FreeBSD 4. What we ended up implementing was the minimal set of netgraph features our application needed, optimized for performance. Passing packets around in batches was one of the performance optimizations. There are some pretty big wins with that approach: amortization of locking costs and other overhead, better cache locality and it's easier to prefetch the data from packet n while processing packet n-1. That's actually one of the ways that we envisioned netgraph being used.. As a prototyping tool that would eventually be replaced by the same node code hooked together be a purpose-designed application. However we did too good a job in implementing it so that for a large percentage of the tasks the prototyping framework actually does well enough. The other use was for low speed L2 plumbing for WAN networking. If I get some time I'll see if I can get something by the way of hard numbers as to the advantages on our application. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] removing broken includes
alex,
I think you are the kind of person to try out
http://code.google.com/p/include-what-you-use/
with fbsd :)
On Thu, Feb 03, 2011 at 10:12:57PM +, Alexander Best wrote:
> hi everybody,
>
> i've started to check the source for broken includes, such as the one fixed in
> r218189. so far i've run through arch=amd64 and found only two broken
> includes,
> which should be fixed by the attached patch. the commands i'm using are:
>
> for target=buildkernel:
> make SRCCONF=/dev/null __MAKE_CONF=/dev/null NO_WARNS= CWARNFLAGS="-w -Werror
> -Wmissing-include-dirs" buildkernel
>
> for target=buildworld:[*]
> make SRCCONF=/dev/null __MAKE_CONF=/dev/null WITHOUT_CDDL=true NO_WARNS=
> CWARNFLAGS="-w -Wmissing-include-dirs" buildworld
>
> next up are the other archs. also i'll try to run both buildworld and
> installworld with "CC=clang -v" and "CXX=clang++ -v". although clang turns
> -Wmissing-include-dirs into a noop, using the -v flag one can still detect
> broken (and even duplicate) includes. thanks to pluknet@ for the info.
>
> cheers.
> alex
>
> [*] the reason i'm setting WITHOUT_CDDL=true is that my installed world was
> compiled with that option. trying to buildworld with CDDL support thus fails.
> also at first i was trying to use the same command for buildworld, as i used
> for buildkernel. however it seems CWARNFLAGS gets set in some places, so
> gcc(1)
> will also treat non -Wmissing-include-dirs warnings as errors.
>
> --
> a13x
> Index: sys/conf/files
> ===
> --- sys/conf/files(revision 218217)
> +++ sys/conf/files(working copy)
> @@ -960,7 +960,7 @@
> dev/e1000/e1000_82571.c optional em | igb \
> compile-with "${NORMAL_C} -I$S/dev/e1000"
> dev/e1000/e1000_82575.c optional em | igb \
> - compile-with "${NORMAL_C} -I$S/dev/igb"
> + compile-with "${NORMAL_C} -I$S/dev/e1000"
> dev/e1000/e1000_ich8lan.coptional em | igb \
> compile-with "${NORMAL_C} -I$S/dev/e1000"
> dev/e1000/e1000_api.coptional em | igb \
> Index: sys/modules/netgraph/atm/ccatm/Makefile
> ===
> --- sys/modules/netgraph/atm/ccatm/Makefile (revision 218217)
> +++ sys/modules/netgraph/atm/ccatm/Makefile (working copy)
> @@ -12,6 +12,6 @@
> SRCS=ng_ccatm.c cc_conn.c cc_data.c cc_dump.c cc_port.c cc_sig.c
> \
> cc_user.c unisap.c
>
> -CFLAGS+= -I${LIBBASE} -I${LIBBASE}/netnatm/ccatm -DCCATM_DEBUG
> +CFLAGS+= -I${LIBBASE} -DCCATM_DEBUG
>
> .include
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] removing broken includes
On Fri, Feb 4, 2011 at 10:53 PM, Roman Divacky wrote: > alex, > > I think you are the kind of person to try out > > http://code.google.com/p/include-what-you-use/ > > with fbsd :) Please be careful with this tool though. There's header pollution in them thar c files (refer to the FreeBSD and/or POSIX manpages for the source of truth), e.g. time.h vs sys/time.h ! HTH, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
