Re: [patch] nmount ro, rw and negated option handling
Hi,
I disagree with your patch and do not approve it.
I prefer something simpler:
Index: vfs_mount.c
===
--- vfs_mount.c (revision 216607)
+++ vfs_mount.c (working copy)
@@ -522,10 +522,9 @@
struct vfsopt *opt, *noro_opt, *tmp_opt;
char *fstype, *fspath, *errmsg;
int error, fstypelen, fspathlen, errmsg_len, errmsg_pos;
- int has_rw, has_noro;
errmsg = fspath = NULL;
- errmsg_len = has_noro = has_rw = fspathlen = 0;
+ errmsg_len = fspathlen = 0;
errmsg_pos = -1;
error = vfs_buildopts(fsoptions, optlist);
@@ -624,7 +623,8 @@
}
else if (strcmp(opt-name, rw) == 0) {
fsflags = ~MNT_RDONLY;
- has_rw = 1;
+ free(opt-name, M_MOUNT);
+ opt-name = strdup(noro, M_MOUNT);
}
else if (strcmp(opt-name, ro) == 0)
fsflags |= MNT_RDONLY;
@@ -642,22 +642,6 @@
}
/*
-* If rw was specified as a mount option, and we
-* are trying to update a mount-point from ro to rw,
-* we need a mount option noro, since in vfs_mergeopts(),
-* noro will cancel ro, but rw will not do anything.
-*/
- if (has_rw !has_noro) {
- noro_opt = malloc(sizeof(struct vfsopt), M_MOUNT, M_WAITOK);
- noro_opt-name = strdup(noro, M_MOUNT);
- noro_opt-value = NULL;
- noro_opt-len = 0;
- noro_opt-pos = -1;
- noro_opt-seen = 1;
- TAILQ_INSERT_TAIL(optlist, noro_opt, link);
- }
-
- /*
* Be ultra-paranoid about making sure the type and fspath
* variables will fit in our mp buffers, including the
* terminating NUL.
ZFS can be changed to check for rw or noro.
--
Craig Rodrigues
rodr...@crodrigues.org
On Fri, Jan 14, 2011 at 02:24:54PM +0200, Jaakko Heinonen wrote:
Hi,
Currently nmount(2) allows a mount point to have ro, rw, and noro
string options concurrently active. This can cause erratic behavior
demonstrated by this example:
1. Have mountd(8) running.
2. # mdconfig -a -t vnode -f ufsimg
3. # mount -o ro,rw /dev/md0 /mnt
After these steps the mount point has string options ro, rw and
noro active but the MNT_RDONLY flag is not set. Eventually this will
lead to ffs_sync: rofs mod (or similar) panic because the ffs code
marks the file system read-only due to the ro string option.
(MNT_RDONLY flag is used in most places for read-only check.)
I wrote a patch to do following changes:
- vfs_equalopts() now recognizes ro and rw as equal options
- vfs_mergeopts() uses vfs_sanitizeopts() to merge options. This ensures
that if the same option shows up several times (negated or not), only
the last one is taken in account. There is still a problem when for
example option foo and nofoo are merged: the nofoo option will
become an active option. This is not a regression however and
currently I don't know an easy way to solve this because the list of
valid options is not available in vfs_mergeopts().
- vfs_donmount() always converts norw/rdonly to ro and noro to
rw. Thus the mount point will always have either rw or ro
option. I haven't seen any in-tree file system to test for noro but
at least ZFS tests for rw. That's why I chose rw instead or
noro.
The patch is available here:
http://people.freebsd.org/~jh/patches/nmount-ro-rw.diff
Reviews and testing would be appreciated.
Here are some references to bug reports which the patch attempts to
resolve:
http://lists.freebsd.org/pipermail/freebsd-current/2009-September/thread.html#11385
http://lists.freebsd.org/pipermail/freebsd-questions/2009-August/204124.html
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/133614
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/150206
--
Jaakko
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: checking zip file corruption
On Mon, Jun 26, 2006 at 09:18:31AM -0400, Ashok Shrestha wrote: Hi all, I am writing code to check if incoming zip files are corrupt and the client is not willing to send a digest (like md5) of the file. Why don't you just use InfoZip's unzip -t flag which tests the integrity of a zip file? You can call unzip -t from Perl. InfoZip is in ports, archivers/unzip and archivers/zip. -- Craig Rodrigues [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: C code for parsing rc.conf?
On Wed, Apr 14, 2004 at 05:14:54PM -0700, Tim Kientzle wrote: There was a detailed discussion of this topic about a year ago. Here is how to obtain the current settings from rc.conf from within a C program: * Clear the current environment * popen() a shell command that sources rc.conf, then runs printenv * read and parse the output of printenv I like this. Would it be worth putting a small writeup of this in the Developer's Handbook? Being able to write programs which can parse and edit rc.conf is actually quite useful in certain cases. An analogy for this would be the API that is used to read/write settings to the Windows registry. On a side note, is there any code in sysinstall that could be reused outside of the sysinstall application in order to parse rc.conf? -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
C code for parsing rc.conf?
Hi, Is there a C library that comes with FreeBSD which can be used to parse, append to, and validate rc.conf? I'd like to customize some of the settings in /etc/rc.conf with my own GUI-based program. It's not too hard to write something on my own, but I was wondering if a reusable library existed in FreeBSD 4.x or 5.x for doing this. Thanks. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
On Fri, Apr 09, 2004 at 10:17:08PM -0700, Lev Walkin wrote: Valgrind is available for FreeBSD. http://eirikn.kerneled.com/valgrind/ Wow!! This is excellent. Is anyone planning to add this to the ports collection? -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel debugging with a multiport serial card
Hi, I have a few FreeBSD machines with an RJ-45 serial connector on the motherboard. I would like to hook these machines up to a single FreeBSD PC with a multiport serial card and set it up to do kernel debugging. Can anyone recommend any multiport serial cards? Are there any cards with known problems? Thanks. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC include files conundrum.
On Mon, Mar 15, 2004 at 08:59:51AM -0600, Jacques A. Vidrine wrote: FreeBSD stopped installing `strstream.h' in January. See rev 1.48 of src/gnu/lib/libstdc++/Makefile. The commit log indicates it was removed in (some release of) GCC 3.3. I wonder if this is correct though--- strstream.h was removed from the FSF GCC sources: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc%2b%2b-v3/include/backward/Attic/strstream.h FreeBSD's import of FSF GCC sources reflects this change. compiler messages seem to contradict this. The compiler message in GCC could be wrong in this particular case for strstream.h. It looks to me like tclmidi uses only class ostrstream. The easiest solution to your problem would be to add a file named `strstream.h' with the following contents: #include strstream using std::ostrstream; The longer term solution is to kill the port, or to port it to Standard C++. Porting it to Standard C++ would probably entail rewriting uses of strstream.h and `ostrstream' to sstream and `ostringstream'; and rewriting uses of other C++ `.h' headers to the standard form without .h; and adding `using namespace std;' liberally. I've fixed a few ports by doing exactly what you have outlined. Admittedly, it's grunt work, but. :) -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC include files conundrum.
On Sun, Mar 14, 2004 at 07:55:18PM -0500, David Gilbert wrote:
I attempted to argue that audio/tclmidi wasn't broken... and the ports
maintainer fired back with
http://bento.freebsd.org/errorlogs/i386-5-latest/tclmidi-3.1.log
Now... I started investigating this and found that this was all due to
some differences in C++ over the years.
So what's the solution?
Pick up a contemporary C++ book and learn about Standard C++ (which became
an ISO standard in 1998). strstream is deprecated in Appendix D
of the standard. I recommend a book such as The C++ Programming
Language, 3rd ed. by Bjarne Stroustrup.
gcc 3.x supports Standard C++ more aggressively than earlier
gcc versions, which can be painful. The GCC developers (more specifically
libstdc++ developers) are more interested in supporting Standard
C++, and are not too interested in maintaining backwards compatibility
with deprecated headers such as strstream.h. This is a bit of a problem
for software that depends on these older libraries.
You have a few options:
(1) Learn enough C++ so that you can apply the necessary patches
to fix audio/tclmidi so that it compiles with
Standard C++ headers (such as sstream).
(2) gcc 3.3 has /usr/include/c++/3.3/backward/strstream, so you may
want to try #include backward/sstream an see if that works,
but chances are if it doesn't work, you will be out of luck,
since it is a deprecated header that the GCC developers
are not too interested in supporting.
(3) In the Makefile for the audio/tclmidi port, mark it as broken
on FreeBSD 5.x:
.if ${OSVERSION} 50
BROKEN= Does not build on 5.x
.endif
--
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Questions about CPU related sysctls
Hi, I want to write some C code to get a count of the number of CPU's on a running system. What is the difference between these two sysctls? kern.smp.cpus: Number of CPUs online hw.ncpu: Number of active CPUs Also, can someone give a brief description of these sysctls (sysctl -d doesn't show anything for them). Would it be a good idea to add some text to these syctls? kern.ccpu: hw.acpi.cpu.cx_history: machdep.hlt_cpus: -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtime signal
On Thu, Jan 29, 2004 at 08:41:39PM +0200, Aliaxandr Pinchuk wrote: FreeBSD 5.1 have a realtime signal support (signal queue)? Not right now. See: http://lists.freebsd.org/pipermail/freebsd-threads/2003-April/68.html -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD VFS System?
On Tue, Dec 16, 2003 at 11:41:33AM -0600, Ryan Sommers wrote: Are there any good web resources or books on the VFS system that the FreeBSD kernel uses? I'm guessing it might have originated from the Recent Filesystem Optimisations in FreeBSD (2002) Ian Dowse, David Malone http://citeseer.nj.nec.com/dowse02recent.html The Design and Implementation of the 4.4 BSD Operating System http://www.aw-bc.com/catalog/academic/product/0,4096,0201549794-TOC,00.html -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Netgraph-ATM used in Masters thesis
Hi, I saw some posts to the cvs-all mailing list recently, giving Harti Brandt a hard time for importing bsnmp to the FreeBSD source tree, so I thought I would post this. :) I recently used Netgraph-ATM as part of my masters thesis at Harvard Extension School, which looked at ATM, CORBA, and network management. My thesis is online at: http://crodrigues.org/thesis_web/ Netgraph-ATM played a big part in my thesis, and Harti was VERY helpful. Harti even extended certain ATM device drivers with sysctl's to get at lower-level register information which allowed me to look at SONET alarm information. The main reason I started using FreeBSD was because of Harti's active maintenance of Netgraph-ATM, versus the less-maintained ATM implementation under Linux. While working on my thesis, I was so impressed with FreeBSD that I switched my home systems over to it, and am still using it, even though my thesis is done. :) I realize that 99% of people out there don't use or care about ATM and bsnmp being in the FreeBSD source tree , but I would just say: - the stability of a lot of Netgraph ATM stuff improved when it got into the tree, since I didn't need to get private patches from Harti - I benefited a lot from it being in the tree (a bit selfish to say, but true) I would like to thank Harti for his hard work on Netgraph-ATM, and all of the FreeBSD committers for producing a great OS and a great piece of software that let me get my work done!! -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux vs FreeBSD clusters (was: how are the Redhat product changes affecting existing and future plans?)
On Thu, Nov 06, 2003 at 04:59:51PM -0800, Rayson Ho wrote: A very good paper about building HPC clusters with FreeBSD: Building a High-performance Computing Cluster Using FreeBSD http://people.freebsd.org/~brooks/papers/bsdcon2003/ The author talked about hardware issues: KVM, BIOS redirection, CPU choices; and then talked about why he chose FreeBSD instead of Linux... he also did the port of GridEngine (SGE) to FreeBSD. Anyone tried to setup HPC clusters with *BSD?? Hi, Not quite the same as an HPC cluster, but take a look at the University of Utah's Emulab: http://www.emulab.net It is heavily based on FreeBSD (i.e. makes use of FreeBSD routing, Dummynet, etc.). The Emulab is a remotely accessible testbed that researchers can use to conduct network experiments. It consists of about 200 PC nodes. The same company that Brooks works for (Aerospace), has apparently set up an internal testbed based on the Emulab software developed at Utah. I use the Emulab every day as party of my research work at BBN, and it is an excellent facility. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Benchmarking kqueue() performance?
Hi, I sent a private e-mail to Jonathan Lemon about this, but thought I would ask the larger FreeBSD community about this as well. Does anyone have any sample code which can be used to benchmark the performance of kqueue() vs. select()? I am interested in setting up a test which handles a large number of events. I am interested in seeing the scalability of kqueue() as the number of events increases. I am also interested in looking at kqueue() performance in multithreaded environmentsmaybe with the new KSE implementation in CURRENT. Thanks. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Makefiles to modify for adding new sys/*.h header files?
Hi,
If I add new headers file in the directories /usr/src/sys/sys
and /usr/src/sys/{arch}/include, then which Makefiles do I need
to modify in order to make sure that my new header files
get installed properly when I do a make installworld?
Thanks.
--
Craig Rodrigues
http://home.attbi.com/~rodrigc
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
#warning must be protected by #if __GNUC__ in headers?
Hi, In sys/syslimits.h, I see: #if __GNUC__ #warning No user-serviceable parts inside. #endif Does the use of #warning need to be protected by #if __GNUC__ in FreeBSD header files? I am working on something similar for machine/limits.h. Some other header files check for __GNUC__ before using #warning, such as sys/ioctl.h, but sys/dkstat.h does not. Thanks. -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD device driver question
On Mon, Feb 10, 2003 at 10:13:28AM -0800, [EMAIL PROTECTED] wrote: Hi. I am looking at writing a FreeBSD device driver for a new PCI card. I looked at the FreeBSD documentation on device drivers (PCI) but couldn't find much. Can anyone point me at appropriate references/documentation (4.*) or URL? FreeBSD Developer's Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ section 24 PCI Devices -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: freebsd running on a cdrom
On Thu, Jan 02, 2003 at 02:03:50PM -0800, Joe wrote: Without building the entire FreeBSD distro how do I make my own boot.flp file and what goes on it? See if this article can help you: Building a CD Bootable Firewall http://www.bsdtoday.com/2002/March/Features646.html -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pw(8): $ (dollar sign) in username
On Fri, Dec 27, 2002 at 11:35:45AM -0600, Ryan Thompson wrote: Problem is, smb requires a '$' at the end of the username, which our pw(8) doesn't allow. The same patch which you proposed was suggested on the freebsd-current list. See the thread pw_user.c change for samba: http://docs.freebsd.org/mail/archive/2002/freebsd-current/20021201.freebsd-current.html http://docs.freebsd.org/mail/archive/2002/freebsd-current/20021208.freebsd-current.html I'm not sure what the outcome of the discussion was. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in -STABLE on P4/2GHz
On Sun, Nov 17, 2002 at 11:16:54PM +0200, Maxim Sobolev wrote: Hi there, I'm observing very strange memory corruption problems with 2GHz P4 system running 4.7 (security branch as of today). Under the load (make -j20 buildworld) the compiler or make(1) often die with signal 11. I found in mailing lists that there is similarly looking problem with -current, any chances that -stable is affected as well? I'm seeing similar errors on -current on my AMD K6-2 machine: CPU: AMD-K6(tm) 3D processor (400.91-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x58c Stepping = 12 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX AMD Features=0x8800SYSCALL,3DNow! Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Write Allocate Enable Limit: 384M bytes Write Allocate 15-16M bytes: Enable I am seeing make or /usr/libexec/cc1 intermittently coredump with SIG 11 or SIG 10 errors when trying to do a buildworld. I wasn't sure if it was because I had flaky hardware or not. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Problem detecting POSIX symbolic constants
On Thu, Oct 10, 2002 at 09:31:56PM +1000, Bruce Evans wrote: Perhaps because they wanted you to use sysconf() instead of these mistakes. Well in the case of ACE, it is a C++ library that is compiled on platforms which may or may not have sysconf() (ie. Windows), so using sysconf() is not practical in this case. Checking a feature macro is much easier. This is variant of the above verbose version. It requires slightly more modern compilers, so it might fail for some 20-year old pre-Standard C compilers instead of only for some 25-year old ones. ACE makes some pretty aggressive use of C++ features, so luckily compliance with 20-25 year old compilers is not a requirement. :) Support for gcc 2.7.2 and 2.8 compilers was dropped recently. It will be really exciting to use ACE on FreeBSD 5.x since gcc 3.2.1 has some fairly good support for modern C++ features. I used a variant your patch for this in PR 35924 until recently when Wow, I forgot that I filed 35924! :) Thanks for reminding me. I noticed that it usually worked for the bogus reason that unistd.h is not included, then _POSIX_REALTIME_SIGNALS is only defined accidentally (to whatever value). I now use just #if 0 and an XXX comment as a reminder to fix this someday: %%% Index: signal.h === RCS file: /home/ncvs/src/include/signal.h,v retrieving revision 1.19 diff -u -2 -r1.19 signal.h --- signal.h 6 Oct 2002 21:54:08 - 1.19 +++ signal.h 7 Oct 2002 07:06:19 - @@ -78,9 +79,18 @@ #if __BSD_VISIBLE || __POSIX_VISIBLE = 199506 || __XSI_VISIBLE = 600 +#if 0 +/* + * PR: 35924 + * XXX we don't actually have these. We set _POSIX_REALTIME_SIGNALS to + * -1 to show that we don't have them, but this symbol is not necessarily + * in scope (in the current implementation), so we can't use it here. + */ int sigqueue(__pid_t, int, const union sigval); +struct timespec; int sigtimedwait(const sigset_t * __restrict, siginfo_t * __restrict, const struct timespec * __restrict); int sigwaitinfo(const sigset_t * __restrict, siginfo_t * __restrict); #endif +#endif #if __BSD_VISIBLE || __POSIX_VISIBLE = 200112 || __XSI_VISIBLE %%% The patch also moves the forward declaration of struct timespec near to the one place that it is used (related patches not included). This mainly makes it obvious that the messy visibility for it is the same as the one for the function that uses it. This patch works for me. I think it is just as easy to just remove cruft from the header file entirely, but since your patch effectively does the same thing and has informative comments, that is fine. If your patch (or some equivalent variant) is committed, then I think PR 35924 can be closed. Something needs to be done about these prototypes. Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C-2(Security) blues and the like
On Thu, Oct 10, 2002 at 06:34:30PM -0400, Robert Watson wrote: Are ISO standards still on the order of US$9 per single-sided page? I just got my copies of the ECMA standards on CDROM (for free...). You can get ISO 15408 (Common Criteria) from ANSI: http://webstore.ansi.org/ansidocstore/find.asp?find_spec=15408 3 PDF files for $18 each, for a total of $54. Paper copies cost more. Actually, I believe that the CC should be available for free on the web somewhere. Unfortunately, I forget where. Last time I got it, it was a free PDF download. A quick google search of Common Criteria yields: http://csrc.nist.gov/cc/ccv20/ccv2list.htm It has PDF files for download which are not the same as the ISO standard, but are supposed to be aligned with ISO 15408. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD usage in safety-critical environments
On Wed, Oct 09, 2002 at 01:08:46PM -0400, Nelson, Trent . wrote: The report 'identifies' that it would be possible to certify Linux to SIL 1 and SIL 2 quite easily, and SIL 3 with a little work. I've seen this game before with other certification efforts, ie. U.S. Federal Aviation Administration's DO-178B for certification of software used in airborne systems and equipment. Certification is usually an expensive undertaking, so it usually requires a company with enough $$$ to jump through all the hoops of the certification process (ie. submitting to special tests, fixing the bugs, etc.). No one would go through this stuff unless there was an anticipated reward, ie. $$$. WindRiver has done this kind of stuff for VxWorks. Now, if the UK govt. is looking to certify Linux, what version and what vendor would they certify? Linux has a lot of buzz these days, and there are a number of vendors who are trying to pitch it in real-time and embedded systems markets, and many companies who are providing Linux-based services. I'm sure that any FreeBSD could be certified, but the questions would be: - which companies have the resources to submit to such an SIL certification and jump through all the hoops? - is there enough of a financial incentive to do so? - has the UK govt heard of BSD, and would they even care if someone wanted to certify it? Unfortunately marketing and mindshare plays a lot in these kinds of things. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD usage in safety-critical environments
On Wed, Oct 09, 2002 at 02:03:32PM -0400, Steve Kudlak wrote: Is there a place for *BSD security freaks to go and discuss systems? I get lots of security questions, usually these are broad level questions and nothing like the government authority certification body sorts of things. Usually they are the usual user questions that come to systems people. The folks that faint when they see me reading FreeBSD hackers and go: How can you read that... As an aside right now my big thing is convincing people in remote areas that *nix, FreeBSD et al provide a clear and better alternative to windows. Your question is a bit off-topic in terms of certification, although security is an important part of safety. See the list of FreeBSD mailing lists: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL freebsd-security or freebsd-security-notifications might be appropriate for your needs. There is a lot of FreeBSD security-related work going on in the TrustedBSD project ( http://www.trustedbsd.org ). Another BSD project, OpenBSD ( http://www.openbsd.org ), has security and safety as its primary focus. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Problem detecting POSIX symbolic constants
Hi, Earlier this year on the FreeBSD hackers mailing list: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=278142+0+/usr/local/www/db/text/2002/freebsd-hackers/20020317.freebsd-hackers I was advised by Terry Lambert to use: #ifdef _POSIX_REALTIME_SIGNALS to detect if sigqueue(), sigtimedwait, sigwaitinfo() were defined. I made this change to the FreeBSD configuration for ACE, a C++ library used for systems programming ( http://www.cs.wustl.edu/~schmidt/ACE.html ). The change I made worked fine in -STABLE. However, in -CURRENT, this test breaks, because _POSIX_REALTIME_SIGNALS is defined, but it is -1. According to the letter of the law: http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html The following symbolic constants shall either be undefined or defined with a value other than -1. So, this is legal way to implement these macros. It just breaks my code. :) Can I appeal to the freebsd-standards team to leave these macros undefined instead of defining them to -1? #ifdef/#ifndef is a pretty common way to detect if a feature is available on a system, especially when used in conjunction with something like autoconf. If that is not an option, then what is the correct way for me to write my code? Keep in mind that code in ACE must be very portable, and work on platforms which may not adhere 100% to the letter of the POSIX law. Unfortunately ACE does not use autoconf, so these configurations need to be hardcoded. Here is my code, from config-freebsd-pthread.h from ACE: 210 #include unistd.h 211 #include signal.h 212 /* POSIX Realtime signals are not fully implemented in FreeBSD. 213When they are implemented, then _POSIX_REALTIME_SIGNALS will be 214defined, as specified in the POSIX standard. 215Refer to e-mail thread on freebsd-hackers mailing list, March 2002. */ 216 #ifdef _POSIX_REALTIME_SIGNALS 217 #define ACE_HAS_AIO_CALLS 218 #ifndef SIGRTMIN 219 # define SIGRTMIN 32 220 #endif /* SIGRTMIN */ 221 #ifndef SIGRTMAX 222 # define SIGRTMAX (_SIG_MAXSIG - 1) 223 #endif /* SIGRTMAX */ 224 #endif /* _POSIX_REALTIME_SIGNALS */ Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Problem detecting POSIX symbolic constants
On Wed, Oct 09, 2002 at 07:29:48PM -0700, Terry Lambert wrote: To be totally correct, you will need to: #ifdef _POSIX_REALTIME_SIGNALS #if (_POSIX_REALTIME_SIGNALS != -1) ... #endif #endif It's annoying, but doing this will ensure that there are no gaps through which some system other than FreeBSD might fall. Sigh. Why did the POSIX guys do this? :( BTW, I think that: #if defined(_POSIX_REALTIME_SIGNALS) (_POSIX_REALTIME_SIGNALS != -1 ) should suffice, but I'll double-check with one of my portability gurus to see if that is OK for ACE. I have another request. Even though my preprocessor check was bogus, ACE still compiled, and I did not discover that there were any problems until link time, ie. I had a libACE.so library which could not link with anything because of unresolved symbols. This was very annoying. It would have been nicer if this could have been caught earlier in the compile stage. Since sigqueue(), sigwait(), sigwaitinfo() are not implemented in FreeBSD, is this patch OK? --- src/include/signal.h.orig Wed Oct 9 23:15:21 2002 +++ src/include/signal.hWed Oct 9 23:15:31 2002 @@ -76,13 +76,6 @@ int sigwait(const sigset_t *, int *); #endif -#if __BSD_VISIBLE || __POSIX_VISIBLE = 199506 || __XSI_VISIBLE = 600 -int sigqueue(__pid_t, int, const union sigval); -int sigtimedwait(const sigset_t * __restrict, siginfo_t * __restrict, -const struct timespec * __restrict); -int sigwaitinfo(const sigset_t * __restrict, siginfo_t * __restrict); -#endif - #if __BSD_VISIBLE || __POSIX_VISIBLE = 200112 || __XSI_VISIBLE int killpg(__pid_t, int); int sigaltstack(const stack_t * __restrict, stack_t * __restrict); At some point in the future when POSIX RT signals are implemented in FreeBSD (I'm not volunteering :), then _POSIX_REALTIME_SIGNALS can be defined to 200112L in unistd.h, and these three prototypes can be put back into signal.h. Is this OK? Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
How to remote debug a network device driver?
Hi, I am trying to learn about FreeBSD kernel development. I have set up two machines with -CURRENT, and have connected them via null modem cable. I have followed the instructions in the Developer's Handbook, On-Line Kernel Debugging Using Remote GDB ( http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x9972.html ) and can successfully debug remotely using gdb. What I am interested in doing is learning more about how the FreeBSD networking system works. What I would like to do is, from machine A, ping machine B. On machine A, I would like to set a breakpoint in the network device driver when the upper layers in the networking stack calls the device driver to transmit data. I am interested in debugging the following drivers: - fatm , from Harti Brandt's Netgraph ATM subsystem: http://www.fokus.fhg.de/research/cc/cats/employees/hartmut.brandt/ngatm/ - fxp, the Intel EtherExpress Pro driver Can someone give me some hints as to where a good place to set the breakpoints would be, or pointers to further information about FreeBSD networking? Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ACPI programming under FreeBSD?
Hi, I am interested in retrieving power statistics type of information from a system running FreeBSD. I am interested in information such as: power consumed, temperature, percentage of battery available, etc. Is it possible to do this with ACPI, and if so, are there any examples of how to gather this information at the user-level? How stable is ACPI support in -STABLE and -CURRENT for this kind of work? Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: POSIX message queue
On Mon, Sep 30, 2002 at 12:21:40AM -0400, Craig Rodrigues wrote: On Sun, Sep 15, 2002 at 11:14:20PM -0400, Dmitriy Fitisov wrote: Hi, I cannot find implementation of POSIX message queues (mq_open, mq_xxx, ...). Even though there is a message header mqueue.h ld cannot find a library. OK, this was just clarified on freebsd-standards. It looks like mqueue.h is not implemented. See: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=10929+0+current/freebsd-standards -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Comments on new Linux threading implementation?
Hi, I saw this post on the Linux kernel mailing list which describes a major re-write of the POSIX threads implementation on Linux: http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.2/1075.html How does this stuff under Linux compare to the scheduler activation type work going on under FreeBSD ( http://people.freebsd.org/~julian/threads/ )? Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: POSIX message queue
On Sun, Sep 15, 2002 at 11:14:20PM -0400, Dmitriy Fitisov wrote: Hi, I cannot find implementation of POSIX message queues (mq_open, mq_xxx, ...). Even though there is a message header mqueue.h ld cannot find a library. Am I looking in wrong place? Thanks. Dmitriy Fitisov I think that you need to specify the following in your kernel config file for POSIX message queues: options P1003_1B#Posix P1003_1B real-time extensions (Read the man page, p1003_1b). The source code for this stuff is in /usr/src/sys/posix4/ However, I'm not sure if this stuff works, or is maintained. You may want to check on the [EMAIL PROTECTED] mailing list. I just asked about p1003_1b and POSIX message queues on that list. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kqueue
On Wed, Sep 25, 2002 at 04:54:25PM +0300, vijay singh wrote: Hi, this is in no way related to the kqueue question asked below but to event notification mechanisms in general. I was wondering if there is some paper or design that talks about how such a facility could be provided in a Unix type kernel. Kqueue is fairly recent, and I dont know what its requirements are but I'm thinking of providing this for an old 2.x FreeBSD system. Any ideas, pointers or suggestions are appreciated. There is a good kqueue paper on Jonathan Lemon's web page which has pointers to further references: http://people.freebsd.org/~jlemon/ -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to correctly detect POSIX 1003.1b features on FreeBSD?
On Tue, Mar 12, 2002 at 11:32:25PM -0800, Terry Lambert wrote: The POSIX specification itself is a better reference for POSIX. The copy I have is old, and the Single Unix Specifications I have (the Go Solo 2, and the earlier Draft of the Spec. 1770 from the UNIX International FTP site before it dies in the mid 1990's) aren't exactly the same thing as POSIX (they are X/Open documents, not IEEE). Unfortunately, the real thing is expensive, but necessary, if you are going to use the features it defines in as portable a way as possible. The Single UNIX Specification, Version 3 was released recently, incorporating POSIX 1003.1-2001. I think the standard is available for free (unlike the older POSIX standards) on the web: http://www.unix-systems.org/version3/ The RT stuff is the one listed; the AIO stuff, I'd have to look up; have you found it yet? Or do I need to go diving? The AIO stuff looks to be there in FreeBSD for the most part. Unfortunately in ACE, there is a interdependency between the AIO code and RT signals, so you either have to have all the features implemented, or you can't use any of them. Is there a maintainer or set of maintainers who looks at POSIX stuff for FreeBSD? I notice that in /usr/src/sys/posix4/, there is some code for things like POSIX message queues. Is that code maintained, or has it been deprecated in favor of kqueue? I don't want to get into a debate about the technical merits of POSIX, but I have worked on some projects where adhering to POSIX api's was actually a project requirement due to customer demand. Thanks again. -- Craig RodriguesDistributed Systems and Logistics, Office 6/304 [EMAIL PROTECTED] BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
How to correctly detect POSIX 1003.1b features on FreeBSD?
Hi, I am currently using FreeBSD 4.3, and am working with ACE, a cross-platform C++ library for doing systems programming (networking, threading, I/O, etc.). I am having problems with the configuration of ACE on FreeBSD, related to POSIX 1003.1b features. Can someone tell me how a user can, at compile time, determine the presence or absence of POSIX 1003.1b features such as: sigwaitinfo sigtimedwait sigqueue Currently, I have some code that does: #if (__FreeBSD_version 44) # define _P1003_1B_VISIBLE # define ACE_HAS_AIO_CALLS # define SIGRTMIN 32 # define SIGRTMAX (_SIG_MAXSIG - 1) #endif This test is wrong, because it fails on FreeBSD 4.5. If I read the posix4(9) man page, it says that I need to check _POSIX_VERSION, _POSIX_C_SOURCE, and _POSIX_SOURCE macros to detect what POSIX features are available. If I look in sys/_posix.h, I see: #ifdef _KERNEL . . . #if (!defined(_POSIX_SOURCE) !defined(_POSIX_C_SOURCE)) || \ (_POSIX_VERSION = 199309L defined(_POSIX_C_SOURCE) \ _POSIX_C_SOURCE = 199309L) #define _P1003_1B_VISIBLE #define _P1003_1B_VISIBLE_HISTORICALLY #endif . . . #endif Can I re-use this test to determine if I have the POSIX 1003.1b functions: sigwaitinfo, sigtimedwait, sigqueue available? In signal.h, I see the following: #ifdef _P1003_1B_VISIBLE __BEGIN_DECLS int sigqueue __P((_BSD_PID_T_, int, const union sigval)); int sigtimedwait __P((const sigset_t *, siginfo_t *, const struct timespec *)); int sigwaitinfo __P((const sigset_t *, siginfo_t *)); __END_DECLS #endif Any clarification on how to correctly detect and use these features, would be appreciated. -- Craig RodriguesDistributed Systems and Logistics, Office 6/304 [EMAIL PROTECTED] BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to correctly detect POSIX 1003.1b features on FreeBSD?
On Tue, Mar 12, 2002 at 01:33:32PM -0800, Terry Lambert wrote: If I read the posix4(9) man page, it says that I need to check _POSIX_VERSION, _POSIX_C_SOURCE, and _POSIX_SOURCE macros to detect what POSIX features are available. THat's *CHECK*, _not_ *SET*. If something begins with an _, it's for you to check, not for you to set. I understand. I didn't write the code in ACE that sets _P1003_1B_VISIBLE, so I am trying to fix it in the correct manner. #if (!defined(_POSIX_SOURCE) !defined(_POSIX_C_SOURCE)) || \ (_POSIX_VERSION = 199309L defined(_POSIX_C_SOURCE) \ _POSIX_C_SOURCE = 199309L) #define _P1003_1B_VISIBLE #define _P1003_1B_VISIBLE_HISTORICALLY #endif The other question I have is, when is _P1003_1B_VISIBLE actually defined? In sys/_posix.h, it looks like that _P1003_1B_VISIBLE is only defined if _KERNEL is defined. So, this macro is only defined if you are compiling kernel code. For user-level (not kernel level) code, is it better to check the _POSIX_SOURCE, _POSIX_VERSION, and _POSIX_C_SOURCE myself, with: #if (!defined(_POSIX_SOURCE) !defined(_POSIX_C_SOURCE)) || \ (_POSIX_VERSION = 199309L defined(_POSIX_C_SOURCE) \ _POSIX_C_SOURCE = 199309L) /* put code which requires 1003.1b here */ #endif Also, can someone tell me what _POSIX_VERSION expand to on FreeBSD current? On FreeBSD 4.3, it expands to: 199009L What is the status of the asynch I/O code in FreeBSD current? Is it compiled in by default, or is it still an option? Thanks. -- Craig RodriguesDistributed Systems and Logistics, Office 6/304 [EMAIL PROTECTED] BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to correctly detect POSIX 1003.1b features on FreeBSD?
Hi,
I compiled this simple program with gcc 2.95 on FreeBSD 4.3:
#include signal.h
int main(int argc, char *argv[])
{
sigqueue(0,0,(union sigval)0);
sigtimedwait((sigset_t *)0, (siginfo_t *)0, (struct timespec *)0);
sigwaitinfo((sigset_t *)0, (siginfo_t *)0);
return 0;
}
% gcc test.c
/tmp/cc6AHohn.o: In function `main':
/tmp/cc6AHohn.o(.text+0x11): undefined reference to `sigqueue'
/tmp/cc6AHohn.o(.text+0x22): undefined reference to `sigtimedwait'
/tmp/cc6AHohn.o(.text+0x31): undefined reference to `sigwaitinfo'
If I look in signal.h, I find:
#ifdef _P1003_1B_VISIBLE
__BEGIN_DECLS
int sigqueue __P((_BSD_PID_T_, int, const union sigval));
int sigtimedwait __P((const sigset_t *, siginfo_t *, const struct timespec *));
int sigwaitinfo __P((const sigset_t *, siginfo_t *));
__END_DECLS
#endif
So, apparently _P1003_1B_VISIBLE is somehow being defined by the
header files, but these particular functions are not available.
Can someone tell me how I can detect if these functions are available
on a system at compile time? I cannot use an autoconf type of test,
and need to use a preprocessor macro type of test.
It seems to me that this particular definition of _P1003_1B_VISIBLE
is broken if it is enabling symbols in header files to appear
which cannot be linked on a generically configured FreeBSD system.
Thanks.
--
Craig RodriguesDistributed Systems and Logistics, Office 6/304
[EMAIL PROTECTED] BBN Technologies, a Verizon company
(617) 873-4725 Cambridge, MA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: How to correctly detect POSIX 1003.1b features on FreeBSD?
On Tue, Mar 12, 2002 at 04:59:40PM -0800, Alfred Perlstein wrote: * Craig Rodrigues [EMAIL PROTECTED] [020312 16:35] wrote: Can someone tell me how I can detect if these functions are available on a system at compile time? I cannot use an autoconf type of test, and need to use a preprocessor macro type of test. __FreeBSD__version. How about giving me useful information, instead of incomplete hints? I already have some code which does: #if (__FreeBSD_version 44) /* Do some stuff which uses sigqueue(), sigwaitinfo(), sigtimedwait() */ #endif That test is broken, because it does work on FreeBSD 4.5 (and probably won't work on 4.6, 4.7, etc.). Is there a version of FreeBSD where sigqueue(), sigwaitinfo(), and sigtimedwait() are available by default? If so, what is this version, and what is the correct value of __FreeBSD_version to check for? If someone goes and re-configures their kernel or libc to contain these functions, will a new preprocessor macro value be defined that I can detect? -- Craig RodriguesDistributed Systems and Logistics, Office 6/304 [EMAIL PROTECTED] BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to correctly detect POSIX 1003.1b features on FreeBSD?
On Tue, Mar 12, 2002 at 05:22:45PM -0800, Smith, Malcolm wrote:
Craig,
It looks to me like the linker is complaining. Do you need to add -posix4
or some such thing to your gcc call?
There is no such flag.
And -lposix4 does not link because there is no
libposix4.{so,a} library.
I went one step further:
cd /usr/lib
sh -c 'for i in `ls *.a`; do printf $i\n=\n; nm $i | egrep
sigqueue|sigwaitinfo|sigtimedwait ; done'
I did not find any library which had siqueue, sigwaitinfo, or sigtimedwait.
--
Craig RodriguesDistributed Systems and Logistics, Office 6/304
[EMAIL PROTECTED] BBN Technologies, a Verizon company
(617) 873-4725 Cambridge, MA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: How to correctly detect POSIX 1003.1b features on FreeBSD?
On Tue, Mar 12, 2002 at 06:02:06PM -0800, Terry Lambert wrote: I told you twice already: I got the e-mail from Albert Perlstein telling me to check __FreeBSD_Version before I got your e-mail telling me to check for _POSIX_REALTIME_SIGNALS. Sorry for the cross-traffic. #ifdef _POSIX_REALTIME_SIGNALS or #if defined(_POSIX_REALTIME_SIGNALS) defined(SIGRTMIN) Isn't this covered in the reference where you are finding the definition of these functions so that you are able to even know how to call them correctly in the first place? No it is not covered. My reference has been the posix4(9) man page, and signal.h which is available on FreeBSD 4.3. I am a contributor to ACE, a cross-platform C++ library for doing systems programming: http://www.cs.wustl.edu/~schmidt/ACE.html. My intent is to fix the macros in ACE which define the configuration on FreeBSD (all FreeBSD specific configuration data is in ACE's config-freebsd-pthread.h). Right now the ACE macros which detect AIO and RT signals are broken, so I am trying to fix these macros, hence my questions on this mailing list. I'm not looking to specifically use POSIX RT signals on FreeBSD, I just want to get ACE to cleanly compile on FreeBSD, so that FreeBSD users can use and enjoy ACE on their projects if they choose. The POSIX standard clearly covers all the feature test macros for the optional implementation parts of the standard, which includes the RT extensions. I wasn't referring to the POSIX standard, I was referring to the signal.h and posix4(9) man page which came with FreeBSD. I'll refer to the POSIX standard from now on. When (if) the feature is ever actuallysupported by FreeBSD, the manifest constant _POSIX_REALTIME_SIGNALS will be defined. Ahh! OK, this is the information that I am most interested in. So, I am now confident to re-write the test in ACE to: #ifdef _POSIX_REALTIME_SIGNALS /* use sigqueue(), etc. */ #endif This test will work for ACE users on older and newer versions of FreeBSD, and when POSIX RT signals are fully implemented on FreeBSD, ACE will use them. Thanks for your help! If you want to support it by writing the code for FreeBSD support yourself, the Linux code is available from: http://hegel.ittc.ukans.edu/projects/posix/signals.html I do not intend to implement POSIX realtime signals for FreeBSD at this time. -- Craig RodriguesDistributed Systems and Logistics, Office 6/304 [EMAIL PROTECTED] BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
