Re: New kernel drivers
On Tue, 10 Aug 1999, eT wrote: Joe Groff wrote: I have a device 'foo' which I'm working on. What files do I need to edit so that config recognizes foo as a controller/pseudo-device/device/disk/whatever? Take a look at /usr/src/sys/i386/files.i386. You device driver files need to have an entry in this file. Also make sure that you have your driver mentioned in your kernel config file. Alternatively it might have an entry in files.MYCONFIG if you don't want to patch a distributed file. eT To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD on VMEbus
Is there anyone using FreeBSD on a VMEbus PC? I have an application which should use VxWorks like the rest of the project, but since this part has been subcontracted, Wind River wants A$35,000 for an expletive deleted OEM licence for the right to link to their libraries. Blood suckers. They only charge A$5990 for the tools! I am being pressured to write a kernel driver for NT to run on the same machine that is doing some pretty heavy FFT calculations using LabView. I want to put a box in between, and if I can't have a realtime operating system, then I need something that I can embedded, like FreeBSD. The question is: out of all the VMEbus PCs available, which one is the best choice based on drivers working out-of-the box? Ethernet is particularly important. For those who are interested, here is a link to the main project: http://www.rlmsystems.com.au/projects.htm (JORN). Please save me from a fate worse than death. I got this contact on the basis that it _wasn't_ a Microsoft development, so either I need to jump off the nearest tall building, walk away, or find an alternative... -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
STAILQ macros..
Hi, I am looking at the STAILQ macros defined in sys/queue.h and I am curious why it is necessary to declare stqh_last in the STAILQ_HEAD as a pointer to pointer, rather than just a pointer? (like the head pointer) Please don't laugh too hard.. my head hurts :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Re: FreeBSD on VMEbus
John Birrell wrote: I have an application which should use VxWorks like the rest of the project, but since this part has been subcontracted, Wind River wants A$35,000 for an expletive deleted OEM licence for the right to link to their libraries. Blood suckers. They only charge A$5990 for the tools! I am being pressured to write a kernel driver for NT to run on the same machine that is doing some pretty heavy FFT calculations using LabView. I want to put a box in between, and if I can't have a realtime operating system, then I need something that I can embedded, like FreeBSD. The question is: out of all the VMEbus PCs available, which one is the best choice based on drivers working out-of-the box? Ethernet is particularly important. We've got a couple of General Micro Systems (www.gms4vme.com) SBC PCs, one single CPU and one dual CPU Pentium. They run Labview and NT fine :( I've booted FreeBSD on them a couple of years ago successfully. These SBCs (Mustang) were nice in that they had on-board aic7880 SCSI controller and DEC 21040 10/100 Ethernet. The newer models (see above web site) look rather nice also (dual Intel 10/100 Ethernet and 53C875 SCSI). A Tundra Universe II chip provides a PCI-VMEbus interface. I've got the full documentation for the chip and it should be possible to make it work under FreeBSD, especially with newbus. You can download the documents for the chip at: http://www.tundra.com/index_prod.cfm?tree_id=100362 This isn't going to work out of the box, but if you only want to memory map VME devices, it shouldn't be that hard to teach FreeBSD that much. The bridge chip provides both master and slave addresses (A16/A24/A32) that look to be easy to configure. The chip also supports mapping of VMEbus interrupts to PCI bus interrupts. For those who are interested, here is a link to the main project: http://www.rlmsystems.com.au/projects.htm (JORN). Please save me from a fate worse than death. I got this contact on the basis that it _wasn't_ a Microsoft development, so either I need to jump off the nearest tall building, walk away, or find an alternative... Supporting VMEbus under FreeBSD is something that we'd like to see also (especially the Tundra chip). Believe it or not, we have had good luck running real-time simulations under Solaris on Force Computers SPARC SBCs with VMEbus. They provide the VMEbus (nexus) driver for Solaris, and you can easily write Solaris drivers for VMEbus devices. mmap is also supported for simply mapping memory to VMEbus devices. We've done both without any problems and have a fully populated 21-slot chassis. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
Dan Moschuk [EMAIL PROTECTED] wrote: A quicker fix would be just to enclose those global variables in mutexes. God, no. The resolver is already stupidly unparallelizable -- there's no need to make it thread-resistant too. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
On Aug 9, 9:21pm, Dan Moschuk wrote: } Subject: Re: gethostbyaddr() and threads. } } | Well, I guess we might as well change the API, since everyone else does. Unless } | someone comes up with a bettter idea, of course :) } | } | -Joe } } The API should not change. There is already enough descrepency between UNIXs } to warrant programs like autoconf, we should not introduce another. } We should introduce a gethostbyaddr_r function, which shouldn't be all that } though to implement. } } From the code that I looked at today, the problems lie inside of glibc. It } declares globally a few static variables that are used by the gethost* } functions. Obviously in a threaded environment, this is bad. } } A nice fix would be to get rid of those variables entirely. A quicker fix } would be just to enclose those global variables in mutexes. Personally, I } like the nicer fix better, which will (unfortunately) involve rewriting most } of the frontends to the res_* functions. } } If no one has any objections, I'd like to start on this tomorrow. You might want to grab the latest BIND release from ftp.isc.org. One of the comments in the CHANGES file from a while ago is: 384. [feature] there is now a nearly-thread-safe resolver API, with the old non-thread-safe API being a set of stubs on top of this. it is possible to program without _res. note: the documentation has not been updated. also note: IRS is a thread-ready API, get*by*() is not. (see ../contrib/manyhosts for an example application.) There's no sense re-inventing any more wheels than necessary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
| Yeah, that IS a horrible idea of mine. :) Changing the API should be a last | resort, though, since we don't want to introduce to many FreeBSDisms into the | already-fragmented-enough Unix world. | | Just a thought, how does Linux's GNU libc handle gethostby* in threaded apps? | | Probably the way POSIX specifies, which would certainly be *our* target. And does POSIX specify it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
Dan Moschuk wrote: | Yeah, that IS a horrible idea of mine. :) Changing the API should be a last | resort, though, since we don't want to introduce to many FreeBSDisms into the | already-fragmented-enough Unix world. | | Just a thought, how does Linux's GNU libc handle gethostby* in threaded apps? | | Probably the way POSIX specifies, which would certainly be *our* target. And does POSIX specify it? You didn't get the message with the function prototypes? I can send it again. This would be the *correct* way to implement thread-safe get*by* calls, since any existing threaded code (Solaris, Linux, etc.) will use these interfaces. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
On Tue, 10 Aug 1999, Wes Peters wrote: Dan Moschuk wrote: | Yeah, that IS a horrible idea of mine. :) Changing the API should be a last | resort, though, since we don't want to introduce to many FreeBSDisms into the | already-fragmented-enough Unix world. | | Just a thought, how does Linux's GNU libc handle gethostby* in threaded apps? | | Probably the way POSIX specifies, which would certainly be *our* target. And does POSIX specify it? You didn't get the message with the function prototypes? I can send it again. This would be the *correct* way to implement thread-safe get*by* calls, since any existing threaded code (Solaris, Linux, etc.) will use these interfaces. Small detail, but having ported a multi-threaded library to Linux either Linux is not posix-compliant or everyone else (solaris and others) is not. It's _r API is quite different. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
Dan Moschuk wrote: Does anyone have any issues with merging the new bind resolver API into libc? Well, Terry does, though I don't quite recall his reasoning. :-) Notice, he objects the way FreeBSD is today, with the bind resolver API inside libc. Of foremost importance, though, check the license. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
"Alton, Matthew" wrote: I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of "The Design and Implementation of the 4.4BSD Operating System" still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? I don't know, but I came across this at SGI: http://oss.sgi.com/projects/xfs/ It looks as though they plan to release it under the GPL. :( Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Tue, 10 Aug 1999, Chris Csanady wrote: I don't know, but I came across this at SGI: http://oss.sgi.com/projects/xfs/ It looks as though they plan to release it under the GPL. :( So? It can still be distributed with FreeBSD. How many people are going to want to modify this code anyway? -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Tue, 10 Aug 1999, Chris Csanady wrote: I don't know, but I came across this at SGI: http://oss.sgi.com/projects/xfs/ It looks as though they plan to release it under the GPL. :( This is why people should start emailing asking for a dual-license that would support incorporation into FreeBSD. If I remember my history right[1], SGI based Irix on BSD extensively and became the first POSIX compatable BSD. See if you can play off some sense of loyalty. Explain to them that using a dual license would permit even further use of the product. Is there a stock "Please use a BSD license instead" letter that is kept around for these purposes? Jamie [1] This is always questionable. And when the history doesn't fit what I need it to say, I change it anyway:) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : Well, Terry does, though I don't quite recall his reasoning. :-) : Notice, he objects the way FreeBSD is today, with the bind resolver : API inside libc. The size of _res has changed. Although it starts with an _, it is officially part of the API. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ppp header size
could you tell me, what size is ppp header on FreeBSD? anton. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Question
Hello All. I have a question. I buy 6 MegaRAID Ultra PCI SCSI Disk Array Controller's and want to use they in FreeBSD, but not found driver. I wrote to [EMAIL PROTECTED] and they siad that no driver for FreeBSD. I found driver for Linux and want use it in FreeBSD 3.1-3.2. How ? P.S. Sorry for my bad english. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Kernel malloc problem?
We are experiencing what appears to be a memory corruption
problem with a kernel device driver running under FreeBSD
2.2.8-STABLE with the CAM patches.
The driver manages a series of memory buffers implemented
using a singly-linked tail list. The number and size of
buffers may be changed via an ioctl call which causes all
of the currently-allocated buffers (one per tail list element)
to be deallocated, and a new set - matching the required buffer
size - to be malloc'ed. The tail queue holding the newly-
allocated buffers is a local copy, and not subject to change
in the event of an interrupt meant for the driver. Given
certain choices for the size and number of buffers, we are observing
corruption of the local copy of the tail queue during and
after the memory allocation process. The corruption usually takes the
form of a NULL pointer overwriting the linking member of a
queue element somewhere in the list, thus rendering some
protions of the allocated memory to be "lost", or non-free-able.
The particular combination of buffer size and number of buffers
which exhibits the problem is:
buffer_size = 8k + 8 bytes (8k buffer + link pointer etc)
num_buffers = 22.
If less than 22 buffers are allocated, the list appears to remain
intact. I'm not sure if it's relavant, but I note that
22 * 8k is just over the 256 kb size, while 21 * 8k is less than this
total.
Here is the snipet of code which builds the list -
STAILQ_INIT(buildlist);
gsio_tossbuffers(sc); /* dump old buffers */
i = args-value;
while(i--) {/* allocate required buffers */
gb = malloc(sizeof(struct gsio_buf) + args-which, M_DEVBUF, M_NOWAIT);
debug(BUF2, "g_freelist + %p", gb);
if (gb == NULL) { /* allocate failed, toss all
* buffers */
debug(BUF, "failed to allocate buffers, freeing");
while ((gb = STAILQ_FIRST(buildlist)) != NULL) {
STAILQ_REMOVE_HEAD(buildlist, g_link);
free(gb, M_DEVBUF);
}
error = ENOMEM;
break;
} else {
STAILQ_INSERT_HEAD(buildlist, gb, g_link);
debug(BUF, "New buffer at %p length 0x%x, next is %p ,tail is %p",
gb, sizeof(struct gsio_buf) + args-which,
gb-g_link.stqe_next,
buildlist.stqh_last);
}
}
---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
PGP signature
Re: Kernel malloc problem?
:size - to be malloc'ed. The tail queue holding the newly- :allocated buffers is a local copy, and not subject to change :in the event of an interrupt meant for the driver. Given If the interrupt scans or in any way accesses the buffer list, you have to disable interrupts temporarily using the appropriate spl*() calls whenever your non-interrupt code (i.e. the ioctl code) makes modifications to the list. Otherwise the interrupt might occur while the list and/or buffers are in an invalid state. If that isn't the problem, look for situations where you might be corrupting memory within the driver. The two most common situations are where you accidently leave references to a buffer you just freed, or where you overrun a buffer. :--- :Daniel O'Connor software and network engineer -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
AccelePort C/X
hi, there! are there any device drivers for any *BSD for DigiBoard AccelePort C/X or should I start writing them myself? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
Joe Groff wrote: On Mon, 9 Aug 1999, Wes Peters wrote: struct rpcent *getrpcent_r(struct rpcent *result, char *buffer, int buflen); Any questions? Looks pretty close to the POSIX/GNU way. Good luck with it. ;^) Straight from the Solaris man pages. Should be as POSIX as working code can be. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: New kernel drivers
On Tue, 10 Aug 1999, eT wrote: Joe Groff wrote: I have a device 'foo' which I'm working on. What files do I need to edit so that config recognizes foo as a controller/pseudo-device/device/disk/whatever? Take a look at /usr/src/sys/i386/files.i386. You device driver files need to have an entry in this file. Also make sure that you have your driver mentioned in your kernel config file. Alternatively it might have an entry in files.MYCONFIG if you don't want to patch a distributed file. eT To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
FreeBSD on VMEbus
Is there anyone using FreeBSD on a VMEbus PC? I have an application which should use VxWorks like the rest of the project, but since this part has been subcontracted, Wind River wants A$35,000 for an expletive deleted OEM licence for the right to link to their libraries. Blood suckers. They only charge A$5990 for the tools! I am being pressured to write a kernel driver for NT to run on the same machine that is doing some pretty heavy FFT calculations using LabView. I want to put a box in between, and if I can't have a realtime operating system, then I need something that I can embedded, like FreeBSD. The question is: out of all the VMEbus PCs available, which one is the best choice based on drivers working out-of-the box? Ethernet is particularly important. For those who are interested, here is a link to the main project: http://www.rlmsystems.com.au/projects.htm (JORN). Please save me from a fate worse than death. I got this contact on the basis that it _wasn't_ a Microsoft development, so either I need to jump off the nearest tall building, walk away, or find an alternative... -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
STAILQ macros..
Hi, I am looking at the STAILQ macros defined in sys/queue.h and I am curious why it is necessary to declare stqh_last in the STAILQ_HEAD as a pointer to pointer, rather than just a pointer? (like the head pointer) Please don't laugh too hard.. my head hurts :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum pgpsX6Pyr7q88.pgp Description: PGP signature
Re: FreeBSD on VMEbus
John Birrell wrote: I have an application which should use VxWorks like the rest of the project, but since this part has been subcontracted, Wind River wants A$35,000 for an expletive deleted OEM licence for the right to link to their libraries. Blood suckers. They only charge A$5990 for the tools! I am being pressured to write a kernel driver for NT to run on the same machine that is doing some pretty heavy FFT calculations using LabView. I want to put a box in between, and if I can't have a realtime operating system, then I need something that I can embedded, like FreeBSD. The question is: out of all the VMEbus PCs available, which one is the best choice based on drivers working out-of-the box? Ethernet is particularly important. We've got a couple of General Micro Systems (www.gms4vme.com) SBC PCs, one single CPU and one dual CPU Pentium. They run Labview and NT fine :( I've booted FreeBSD on them a couple of years ago successfully. These SBCs (Mustang) were nice in that they had on-board aic7880 SCSI controller and DEC 21040 10/100 Ethernet. The newer models (see above web site) look rather nice also (dual Intel 10/100 Ethernet and 53C875 SCSI). A Tundra Universe II chip provides a PCI-VMEbus interface. I've got the full documentation for the chip and it should be possible to make it work under FreeBSD, especially with newbus. You can download the documents for the chip at: http://www.tundra.com/index_prod.cfm?tree_id=100362 This isn't going to work out of the box, but if you only want to memory map VME devices, it shouldn't be that hard to teach FreeBSD that much. The bridge chip provides both master and slave addresses (A16/A24/A32) that look to be easy to configure. The chip also supports mapping of VMEbus interrupts to PCI bus interrupts. For those who are interested, here is a link to the main project: http://www.rlmsystems.com.au/projects.htm (JORN). Please save me from a fate worse than death. I got this contact on the basis that it _wasn't_ a Microsoft development, so either I need to jump off the nearest tall building, walk away, or find an alternative... Supporting VMEbus under FreeBSD is something that we'd like to see also (especially the Tundra chip). Believe it or not, we have had good luck running real-time simulations under Solaris on Force Computers SPARC SBCs with VMEbus. They provide the VMEbus (nexus) driver for Solaris, and you can easily write Solaris drivers for VMEbus devices. mmap is also supported for simply mapping memory to VMEbus devices. We've done both without any problems and have a fully populated 21-slot chassis. Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyaddr() and threads.
Dan Moschuk d...@trinsec.com wrote: A quicker fix would be just to enclose those global variables in mutexes. God, no. The resolver is already stupidly unparallelizable -- there's no need to make it thread-resistant too. Tony. -- f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyaddr() and threads.
On Aug 9, 9:21pm, Dan Moschuk wrote: } Subject: Re: gethostbyaddr() and threads. } } | Well, I guess we might as well change the API, since everyone else does. Unless } | someone comes up with a bettter idea, of course :) } | } | -Joe } } The API should not change. There is already enough descrepency between UNIXs } to warrant programs like autoconf, we should not introduce another. } We should introduce a gethostbyaddr_r function, which shouldn't be all that } though to implement. } } From the code that I looked at today, the problems lie inside of glibc. It } declares globally a few static variables that are used by the gethost* } functions. Obviously in a threaded environment, this is bad. } } A nice fix would be to get rid of those variables entirely. A quicker fix } would be just to enclose those global variables in mutexes. Personally, I } like the nicer fix better, which will (unfortunately) involve rewriting most } of the frontends to the res_* functions. } } If no one has any objections, I'd like to start on this tomorrow. You might want to grab the latest BIND release from ftp.isc.org. One of the comments in the CHANGES file from a while ago is: 384. [feature] there is now a nearly-thread-safe resolver API, with the old non-thread-safe API being a set of stubs on top of this. it is possible to program without _res. note: the documentation has not been updated. also note: IRS is a thread-ready API, get*by*() is not. (see ../contrib/manyhosts for an example application.) There's no sense re-inventing any more wheels than necessary. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyaddr() and threads.
gethostbyaddr... actually, most of the gethostby* functions... are not thread safe. They all use a static buffer in the library. Therefore, with threads, if you don't take precautions, I'd expect your results to be odd. -Brian Couldn't this be easily fixed? I haven't looked at the source yet, but I believe you could replaced the static buffers with a dynamically-allocated list of buffers, with one for each thread using the gethost functions. Or perhaps you could just eliminate all the static stuff altogether? -Joe You could, but thats not what was asked. Nor is the solution portable. Posix warns that these functions are not thread safe. Realistically, the portable solution would be to mutex lock (or equiv.) around the calls, so that only one thread can call the function(s) at a time, and be sure to copy the results out of the temporary buffers before releasing the locks. (see note on if you don't take precautions) An even more interesting solution may be to write some wrappers that do the lock, call the function, and store the result in a thread-specific area, then unlock again. -Brian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyaddr() and threads.
| Yeah, that IS a horrible idea of mine. :) Changing the API should be a last | resort, though, since we don't want to introduce to many FreeBSDisms into the | already-fragmented-enough Unix world. | | Just a thought, how does Linux's GNU libc handle gethostby* in threaded apps? | | Probably the way POSIX specifies, which would certainly be *our* target. And does POSIX specify it? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyaddr() and threads.
| } If no one has any objections, I'd like to start on this tomorrow. | | You might want to grab the latest BIND release from ftp.isc.org. One | of the comments in the CHANGES file from a while ago is: | | 384. [feature] there is now a nearly-thread-safe resolver API, with | the old non-thread-safe API being a set of stubs on | top of this. it is possible to program without _res. | note: the documentation has not been updated. also | note: IRS is a thread-ready API, get*by*() is not. | (see ../contrib/manyhosts for an example application.) | | There's no sense re-inventing any more wheels than necessary. Great! This makes my job even easier! Does anyone have any issues with merging the new bind resolver API into libc? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyaddr() and threads.
Dan Moschuk wrote: | Yeah, that IS a horrible idea of mine. :) Changing the API should be a last | resort, though, since we don't want to introduce to many FreeBSDisms into the | already-fragmented-enough Unix world. | | Just a thought, how does Linux's GNU libc handle gethostby* in threaded apps? | | Probably the way POSIX specifies, which would certainly be *our* target. And does POSIX specify it? You didn't get the message with the function prototypes? I can send it again. This would be the *correct* way to implement thread-safe get*by* calls, since any existing threaded code (Solaris, Linux, etc.) will use these interfaces. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyaddr() and threads.
On Tue, 10 Aug 1999, Wes Peters wrote: Dan Moschuk wrote: | Yeah, that IS a horrible idea of mine. :) Changing the API should be a last | resort, though, since we don't want to introduce to many FreeBSDisms into the | already-fragmented-enough Unix world. | | Just a thought, how does Linux's GNU libc handle gethostby* in threaded apps? | | Probably the way POSIX specifies, which would certainly be *our* target. And does POSIX specify it? You didn't get the message with the function prototypes? I can send it again. This would be the *correct* way to implement thread-safe get*by* calls, since any existing threaded code (Solaris, Linux, etc.) will use these interfaces. Small detail, but having ported a multi-threaded library to Linux either Linux is not posix-compliant or everyone else (solaris and others) is not. It's _r API is quite different. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyaddr() and threads.
Dan Moschuk wrote: Does anyone have any issues with merging the new bind resolver API into libc? Well, Terry does, though I don't quite recall his reasoning. :-) Notice, he objects the way FreeBSD is today, with the bind resolver API inside libc. Of foremost importance, though, check the license. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
Alton, Matthew wrote: I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of The Design and Implementation of the 4.4BSD Operating System still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? I don't know, but I came across this at SGI: http://oss.sgi.com/projects/xfs/ It looks as though they plan to release it under the GPL. :( Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Tue, 10 Aug 1999, Chris Csanady wrote: I don't know, but I came across this at SGI: http://oss.sgi.com/projects/xfs/ It looks as though they plan to release it under the GPL. :( So? It can still be distributed with FreeBSD. How many people are going to want to modify this code anyway? -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: BSD XFS Port BSD VFS Rewrite
Thank you for this link. I assume that SGI will release the XFS code under some species of corporate community licensing scheme. The BSD/XFS will be implemented as an optional bolt-on set of kernel modules in a manner designed to avoid GPL-ifying the BSD kernel. I currently believe that this can be done so long as the modules constitute a discrete product. I will have my lawyer confirm this when the details of the SGI license become public. -Original Message- From: Chris Csanady [SMTP:ccsan...@scl.ameslab.gov] Sent: Tuesday, August 10, 1999 12:38 PM To: Alton, Matthew Cc: 'hack...@freebsd.org' Subject: Re: BSD XFS Port BSD VFS Rewrite Alton, Matthew wrote: I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of The Design and Implementation of the 4.4BSD Operating System still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? I don't know, but I came across this at SGI: http://oss.sgi.com/projects/xfs/ It looks as though they plan to release it under the GPL. :( Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Tue, 10 Aug 1999, Chris Csanady wrote: I don't know, but I came across this at SGI: http://oss.sgi.com/projects/xfs/ It looks as though they plan to release it under the GPL. :( This is why people should start emailing asking for a dual-license that would support incorporation into FreeBSD. If I remember my history right[1], SGI based Irix on BSD extensively and became the first POSIX compatable BSD. See if you can play off some sense of loyalty. Explain to them that using a dual license would permit even further use of the product. Is there a stock Please use a BSD license instead letter that is kept around for these purposes? Jamie [1] This is always questionable. And when the history doesn't fit what I need it to say, I change it anyway:) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyaddr() and threads.
In message 37b05320.e6722...@newsguy.com Daniel C. Sobral writes: : Well, Terry does, though I don't quite recall his reasoning. :-) : Notice, he objects the way FreeBSD is today, with the bind resolver : API inside libc. The size of _res has changed. Although it starts with an _, it is officially part of the API. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyaddr() and threads.
Daniel C. Sobral d...@newsguy.com writes: Of foremost importance, though, check the license. Are we still talking about irs? I don't find any particular strange licenses in src/lib/irs in recent bind distributions: /assar /* * Copyright (c) 1996,1999 by Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED AS IS AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS * SOFTWARE. */ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Using legacy sysinstall to upgrade live system
Hi folks, I've just gotten feedback from PR 12777, in which at least 2 people are complaining that sysinstall as installed by 3.1-RELEASE can not be used to upgrade a live machine to 3.2-RELEASE on the fly. I've told both parties that they need to use a boot floppy with the correct version of sysinstall, or build a 3.2-RELEASE sysinstall from source, and one of the chaps I'm speaking to thinks that this is unreasonable. Before I tell him that diffs are welcome, I thought I'd check that I'm not making a mistake here. I lost my confidence when it was pointed out that sysinstall can be given any arbitrary release name to use for Upgrade without issuing any warnings. So? Am I wrong? If you _are_ supposed to be able to upgrade to any arbitrary release using sysinstall as installed by any prior release, perhaps someone could suggest the cause of the problems reported on the PR? Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
ppp header size
could you tell me, what size is ppp header on FreeBSD? anton. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Question
Hello All. I have a question. I buy 6 MegaRAID Ultra PCI SCSI Disk Array Controller's and want to use they in FreeBSD, but not found driver. I wrote to supp...@ami.com and they siad that no driver for FreeBSD. I found driver for Linux and want use it in FreeBSD 3.1-3.2. How ? P.S. Sorry for my bad english. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Kernel malloc problem?
We are experiencing what appears to be a memory corruption
problem with a kernel device driver running under FreeBSD
2.2.8-STABLE with the CAM patches.
The driver manages a series of memory buffers implemented
using a singly-linked tail list. The number and size of
buffers may be changed via an ioctl call which causes all
of the currently-allocated buffers (one per tail list element)
to be deallocated, and a new set - matching the required buffer
size - to be malloc'ed. The tail queue holding the newly-
allocated buffers is a local copy, and not subject to change
in the event of an interrupt meant for the driver. Given
certain choices for the size and number of buffers, we are observing
corruption of the local copy of the tail queue during and
after the memory allocation process. The corruption usually takes the
form of a NULL pointer overwriting the linking member of a
queue element somewhere in the list, thus rendering some
protions of the allocated memory to be lost, or non-free-able.
The particular combination of buffer size and number of buffers
which exhibits the problem is:
buffer_size = 8k + 8 bytes (8k buffer + link pointer etc)
num_buffers = 22.
If less than 22 buffers are allocated, the list appears to remain
intact. I'm not sure if it's relavant, but I note that
22 * 8k is just over the 256 kb size, while 21 * 8k is less than this
total.
Here is the snipet of code which builds the list -
STAILQ_INIT(buildlist);
gsio_tossbuffers(sc); /* dump old buffers */
i = args-value;
while(i--) {/* allocate required buffers */
gb = malloc(sizeof(struct gsio_buf) + args-which, M_DEVBUF, M_NOWAIT);
debug(BUF2, g_freelist + %p, gb);
if (gb == NULL) { /* allocate failed, toss all
* buffers */
debug(BUF, failed to allocate buffers, freeing);
while ((gb = STAILQ_FIRST(buildlist)) != NULL) {
STAILQ_REMOVE_HEAD(buildlist, g_link);
free(gb, M_DEVBUF);
}
error = ENOMEM;
break;
} else {
STAILQ_INSERT_HEAD(buildlist, gb, g_link);
debug(BUF, New buffer at %p length 0x%x, next is %p ,tail is %p,
gb, sizeof(struct gsio_buf) + args-which,
gb-g_link.stqe_next,
buildlist.stqh_last);
}
}
---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
pgpW4KKiLTChh.pgp
Description: PGP signature
Re: Kernel malloc problem?
:size - to be malloc'ed. The tail queue holding the newly- :allocated buffers is a local copy, and not subject to change :in the event of an interrupt meant for the driver. Given If the interrupt scans or in any way accesses the buffer list, you have to disable interrupts temporarily using the appropriate spl*() calls whenever your non-interrupt code (i.e. the ioctl code) makes modifications to the list. Otherwise the interrupt might occur while the list and/or buffers are in an invalid state. If that isn't the problem, look for situations where you might be corrupting memory within the driver. The two most common situations are where you accidently leave references to a buffer you just freed, or where you overrun a buffer. :--- :Daniel O'Connor software and network engineer -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Kernel malloc problem?
On 11-Aug-99 Matthew Dillon wrote: If the interrupt scans or in any way accesses the buffer list, you have to disable interrupts temporarily using the appropriate spl*() calls whenever your non-interrupt code (i.e. the ioctl code) makes modifications to the list. Otherwise the interrupt might occur while the list and/or buffers are in an invalid state. Yes we have splhigh() around code which modifies any of the lists/pointers that the interrupt routine calls. If that isn't the problem, look for situations where you might be corrupting memory within the driver. The two most common situations are where you accidently leave references to a buffer you just freed, or where you overrun a buffer. Yes, well the we can reproduce the corruption. One place it happens is during the construction of the list (the code I showed you). The list in question is used by _nothing_ else (the list is built and then 'transfered' to the list the interrupt handler will used). The corruption seems to occur while the list is being built, but only with some specific buffer sizes :-/ --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum pgp0QWldDwGK6.pgp Description: PGP signature
AccelePort C/X
hi, there! are there any device drivers for any *BSD for DigiBoard AccelePort C/X or should I start writing them myself? /fjoe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
