Re: How to do proper locking
Hans Petter Selasky wrote: On Friday 05 August 2005 19:29, John Baldwin wrote: Yes, you are right, but the problem is, that for most callback systems in the kernel, there is no mechanism that will pre-lock some custom mutex before calling the callback. Not generally applicable to this case but for example the netgraph callout wrappers handlle netgraph node locking so that teh called function can assume the node it is working on has been locked. It's not applicable because netgraph locking is different to locking elsewhere in the kernel due to the nature of netgraph. But havinng a specific callout wrapper for a subsystem does give the ability to do such things. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Checking sysctl values from within the kernel.
Hi Thordur,
PS: If you don't mind, what is a real accessor function ?
This is a function acting as a wrapper for accessing an integer
declared as static. This function must of course live in the same
file. This may be something like this, there may exist neater
interfaces though :
static int age;
int
age_accessor(int *get, int set)
{
if (get != NULL)
*get = age;
else if (set 0 || set 125)
return -1;
else
age = set;
return 0;
}
If `get' is not NULL, this means the caller wants to retrieve the
current age value. Else, this means the caller wants to set the age
value to a new one : if the latter is lower than 0 and greater than
125, this is an incredible age and the accessor reports an error.
Else it sets the new value.
I hope this helped.
Regards,
--
Jeremie Le Hen
jeremie at le-hen dot org ttz at chchile dot org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD-* files in non-HEAD branches
Hi, On Fri, Aug 05, 2005 at 10:53:12PM -0700, Doug Barton wrote: I'm wondering what the utility of files like FREEBSD-Upgrade and FREEBSD-Xlist which describe how to import stuff in src/contrib in branches other than HEAD. It makes sense to me to remove these files in other brakes, opinions? At least is makes it easy to view diffs between branches. I'd prefer it if you don't remove them from src/contrib/groff/ and src/contrib/texinfo/ at least that I maintain. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpY5f1FxA5IO.pgp Description: PGP signature
Re: FreeBSD-* files in non-HEAD branches
Ruslan Ermilov wrote: Hi, On Fri, Aug 05, 2005 at 10:53:12PM -0700, Doug Barton wrote: I'm wondering what the utility of files like FREEBSD-Upgrade and FREEBSD-Xlist which describe how to import stuff in src/contrib in branches other than HEAD. It makes sense to me to remove these files in other brakes, opinions? At least is makes it easy to view diffs between branches. I'd prefer it if you don't remove them from src/contrib/groff/ and src/contrib/texinfo/ at least that I maintain. Sorry I wasn't clear, I am only considering removing them from src/contrib/bind9. I wouldn't remove them in other people's areas. Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Finding an illegal instruction in gnucash/guile
I recently upgraded gnucash and dependencies and am now getting SIGILL during startup. This originally occurred on 5.3 but I'm getting exactly the same thing running on a recent -CURRENT with a freshly built (from scratch) ports tree. I've tried running gdb on the core dump but the results suggest that gdb is confused. Definitely there's no illegal instruction at the claimed location, though the backtrace doesn't appear trustable (and ISTR that gdb is a bit dodgy on threaded programs). gdb claims the problem is in libguile. I've tried rebuilding it with different CPU and optimisation options (in case I've triggered a gcc bug) but the SIGILL remains. I've had a look through google and not found anything relevant. Does anyone have any suggestions other than rebuilding the ports from scratch with different CPUTYPE and/or CFLAGS? (I'm currently using CPUTYPE=athlon-xp and CFLAGS=-O -g). -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Number of significand bits in long double?
On Fri, Aug 05, 2005 at 05:15:33PM +0400, Denis Antrushin wrote: Steve Kargl wrote: Can someone confirm or refute that the working number of bits in the significand of long double type is 53 on i386? Yes, this is what IEEE 754 requires. (See http://docs.sun.com/source/806-3568/ncg_goldberg.html, section 'The IEEE Standard') BZZZT. You're not even close to correct. See Table 1 in the IEEE 754 standard and then read section 3.4. -- Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Number of significand bits in long double?
On Fri, Aug 05, 2005 at 08:37:44PM +0400, Denis Antrushin wrote: Steve Kargl wrote: On Fri, Aug 05, 2005 at 05:15:33PM +0400, Denis Antrushin wrote: Steve Kargl wrote: Can someone confirm or refute that the working number of bits in the significand of long double type is 53 on i386? Yes, this is what IEEE 754 requires. (See http://docs.sun.com/source/806-3568/ncg_goldberg.html, section 'The IEEE Standard') BZZZT. You're not even close to correct. See Table 1 in the IEEE 754 standard and then read section 3.4. Well, you know the answer then ;-) I know what IEEE-754 specifies. I don't know what FreeBSD implements. In particular, float.h misrepresents long double on i386. -- Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Number of significand bits in long double?
On Fri, Aug 05, 2005 at 11:33:35AM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Steve Kargl [EMAIL PROTECTED] writes: : Can someone confirm or refute that the working number : of bits in the significand of long double type is 53 : on i386? The number of bits is 53. However, you can get more bits by adding a fpsetprec(FP_PE) at the start of the programs. Otherwise, you get FP_PD by default. Once you do that, things seem to basically work, but I've not run paranoia.c to make sure. I'm writing some of the missing C99 long double math functions (to be contributes to FreeBSD). The code assumes 64 bits in the approximations that I'm using. When I try to run test programs to check the accuracy of my implementations against GMP/MPFR ouput, I can't trust the values of LDBL_* reported from float.h. My test programs now include #ifdef AMD64 #define BITSL 64 #define DIGSL 18 #else #define BITSL 53 #define DIGSL 15 #endif instead of #include float.h and the use of LDBL_MANT_DIG and LDBL_DIG. -- Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
SB 3DSE ioctl() patch
(This was originally addressed to Cameron Grant, the author of the files I modified. Unfortunately, my message bounced, and shortly thereafter, I learned that he passed away earlier this year [1]. I hope this forum is an appropriate alternative.) [1] http://lists.nycbug.org/pipermail/talk/2005-March/005014.html Hello, I just installed a Soundblaster 16 (DSP v4.16) in my FreeBSD machine, and found no way to enable the 3D stereo enhancement feature that the Linux, DOS and Win9x drivers support. So I looked at the Linux driver sources and decided to add a compatible mixer ioctl() to the FreeBSD driver. That turned out to be a lot more complicated than expected, because there was no existing interface for this kind of hardware-specific ioctls. After extensive reverse-engineering of the FreeBSD driver model (studying the UART and TTY drivers was particularly helpful), and adding a method to the mixer interface, I managed to implement the feature, at least to the extent that it works for me. Perhaps you could take a look at the patch to verify that it doesn't break anything, and consider adding it to the mainstream kernel? The patch and a utility for testing it is available from my FTP site: ftp://vax.narpes.com/users/aw/freebsd-5.3-aw-3dse.diff ftp://vax.narpes.com/users/aw/s3dioctl.c Regards, A. Wik ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel code of reseting/ignoring tcp SYN packets
** Reply Requested When Convenient ** Hi everyone, I was looking around for the files of Kernel code where SYN messages are sent, so we can simply inject some code to send back a reset messages or ignore the SYN requests. I was looking at the function ioctl() which takes fd of the tcp socket. As i track the function down, there is also another call to the dev_ioclt() function where all parameters are passed down. However, i was not sucessful with finding out the description of this dev_ioclt() function. I am having a bit of trouble in finding out the way of injecting code in the kernel to deal with SYN packets. I am thinking of using ipfw to either reset or drop SYN packets. Would anyone have some hints on the clean way of injecting some code to deal with SYN packets or could you give me some ideas on which files i should look at? I really appreciate that. I saw some promising files in src/sys/netinet but they are not all clear in my mind. Thanks heaps! Swinburne University of Technology CRICOS Provider Code: 00111D NOTICE This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Finding an illegal instruction in gnucash/guile
gdb claims the problem is in libguile. I've tried rebuilding it with different CPU and optimisation options (in case I've triggered a gcc bug) but the SIGILL remains. I've had a look through google and not found anything relevant. Does anyone have any suggestions other than rebuilding the ports from scratch with different CPUTYPE and/or CFLAGS? (I'm currently using CPUTYPE=athlon-xp and CFLAGS=-O -g). I had a similar (if not the same) problem on a 4.11-STABLE machine. Actually, I am running gnucash on two different 4.11-STABLE machines -- on one, it worked, on the other, where I installed it some days ago it didn't. Then, I cvsup'ed both machines and the first port I installed on both was gnucash (the only difference betweeen the two machines was the order the ports were installed) and now, it works on both machines. This information seemed too few to me to file a PR but maybe it helps you. Dirk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
sed s///i
Hi, I would like to implement the 'i' flag for the 's' command in sed(1). This flag would mean that the match must be case insensitive. I'm not willing to implement this to conform to GNU sed(1), I just find it very handy : s/[Ff][Oo][Oo]/bar/ would become s/foo/bar/i Before I start modifying the code, I would like if it is something that has chances to get commited or not, although SUSv3 doesn't talk about this flag. I also need to add that this change would be a little intrusive in the code. Actually the regular expression gets compiled, then the substitute string and finally flags are handled. Thus this would require scanning flags before compiling the regular expression. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
pthreads problem
Hi!
From the what's-wrong-with-my-code department...
I'm having trouble with two threads accessing a queue. One thread
writes to it while the other one reads from the queue. I'd like the
consumer to run until the main thread (which is the producer) decides
that the consumer thread should exit.
Let me show you some example code to illustrate what I'm currently
doing. The consumer runs in an endless loop until it is being cancelled
by the main thread using pthread_cancel():
void *thread_routine(void *args) {
while (1) {
pthread_mutex_lock(m);
if (len == 0)
pthread_cond_wait(notempty, m);
printf(consumer: %i\n, --len);
pthread_cond_signal(notfull);
if (len == 0)
pthread_cond_signal(isempty);
pthread_mutex_unlock(m);
}
return (NULL);
}
I belive the only cancellation point here is pthread_cond_wait(), so
the main thread cancels the consumer while it is waiting on the notempty
condition and the mutex m will not be destroyable.
pthread_mutex_lock(m);
if (len 0) {
printf(Waiting for consumer...\n);
pthread_cond_wait(isempty, m);
}
pthread_mutex_unlock(m);
pthread_cancel(t);
pthread_join(t, NULL);
pthread_cond_destroy(notfull);
pthread_cond_destroy(notempty);
pthread_cond_destroy(isempty);
error = pthread_mutex_destroy(m);
if (error)
printf(%s\n, strerror(error));
If the main thread holds the mutex over both the pthread_cancel() and
pthread_join() calls, a deadlock occurs where the consumer waits on the
notempty condition and the main thread waits on the consumer:
pthread_cancel(t);
pthread_join(t, NULL);
pthread_mutex_unlock(m);
So, what is the best way to solve this problem? Introduce a variable for
the while-loop like while (running) { .. }? Have the consumer poll if
there is data in the queue?
I hope somebody can help me.
TIA,
Phil.
P.S:: Attached is the full example.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pthreads problem
Philip S. Schulz wrote: P.S:: Attached is the full example. Oh, well, apparently I'm too dumb to use my mail reader correctly... it is at http://aliue.homeunix.net:8000/threads.c Phil. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to do proper locking
In message [EMAIL PROTECTED], Hans Petter Selasky writes: Yes, you are right, but the problem is, that for most callback systems in the kernel, there is no mechanism that will pre-lock some custom mutex before calling the callback. I am not speaking about adding lines to existing code, but to add one extra parameter to the setup functions, where the mutex that should be locked before calling the callback(s) can be specified. If it is NULL, Giant will be used. The setup functions I have in mind are for example: make_dev(), bus_setup_intr(), callout_reset() ... and in general all callback systems that look like these. Note that FreeBSD's callout subsystem does already have such a mechanism. Just use callout_init_mtx() and the specified mutex will be acquired before the callback is invoked. See callout(9) for more details. Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel code of reseting/ignoring tcp SYN packets
On Sat, 6 Aug 2005, Minh Tran wrote: Would anyone have some hints on the clean way of injecting some code to deal with SYN packets or could you give me some ideas on which files i should look at? I really appreciate that. I saw some promising files in src/sys/netinet but they are not all clear in my mind. Thanks heaps! I don't have any idea what you are asking, so I can't answer your question. Before proceeding, it would probably be worth your while to find a copy of Stevens's TCP/IP Illustrated Volume 2 and at least skim it so that you have a better idea of how the connection establishment process works. The book describes an earlier version of the BSD TCP/IP stack, but much still applies. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel code of reseting/ignoring tcp SYN packets
On Sat, 6 Aug 2005, Minh Tran wrote:
I was looking around for the files of Kernel code where SYN messages are
sent, so we can simply inject some code to send back a reset messages or
ignore the SYN requests. I was looking at the function ioctl() which
takes fd of the tcp socket. As i track the function down, there is also
another call to the dev_ioclt() function where all parameters are passed
down. However, i was not sucessful with finding out the description of
this dev_ioclt() function. I am having a bit of trouble in finding out
the way of injecting code in the kernel to deal with SYN packets. I am
thinking of using ipfw to either reset or drop SYN packets.
Would anyone have some hints on the clean way of injecting some code to
deal with SYN packets or could you give me some ideas on which files i
should look at? I really appreciate that. I saw some promising files in
src/sys/netinet but they are not all clear in my mind.
TCP packet input processing occurs in
src/sys/netinet/tcp_input.c:tcp_input(). This is a very large function,
so you will want to search for the following line, which precedes
responsible for the processing of SYN packets that will form new
connections:
if (so-so_options SO_ACCEPTCONN) {
FreeBSD makes use of a combined syncache/syncookie mechanism, so you're
probably also interested in tcp_syncache.c.
Robert N M Watson
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel code of reseting/ignoring tcp SYN packets
Minh Tran wrote: ** Reply Requested When Convenient ** Hi everyone, I was looking around for the files of Kernel code where SYN messages are sent, so we can simply inject some code to send back a reset messages or ignore the SYN requests. I was looking at the function ioctl() which takes fd of the tcp socket. As i track the function down, there is also another call to the dev_ioclt() function where all parameters are passed down. However, i was not sucessful with finding out the description of this dev_ioclt() function. I am having a bit of trouble in finding out the way of injecting code in the kernel to deal with SYN packets. I am thinking of using ipfw to either reset or drop SYN packets. that's what I would do as it already has that option. reset or drop keywords. reset Discard packets that match this rule, and if the packet is a TCP packet, try to send a TCP reset (RST) notice. The search termi- nates. in addition, in 6.x (or is it just 7?) you can hook an ipfw rule directly into a netgraph node that you have loaded that could do arbitrary processing. and even pass it back. Would anyone have some hints on the clean way of injecting some code to deal with SYN packets or could you give me some ideas on which files i should look at? I really appreciate that. I saw some promising files in src/sys/netinet but they are not all clear in my mind. Thanks heaps! Swinburne University of Technology CRICOS Provider Code: 00111D NOTICE This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
