Re: Fix/tuning to improve slow NFS writes?
: So, the big question is whether there is anything we can tune to speed up :the writes. The freebsd machines are NFS clients to the sun servers doing :most of the web processing. Overall performance on the reads seems to be :best with nfs v3 over udp, which is what I'm using now. All of the web :server directories are soft mounted directly, with no amd currently in use. : :thanks, : :Doug Well, NFS buffers are usually sent over the network the moment they are full. If you are not running any nfsiod's, the RPC will be done synchronously and this will severely impact your performance. Try running: nfsiod -n 4 This will start up a couple of special background processes to handle NFS I/O asynchronously. Without any nfsiod's running my file tests weigh in at 2 MBytes/sec. With a couple running I get 8 MBytes/sec over my network with NFSv3. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Fix/tuning to improve slow NFS writes?
Matthew Dillon wrote: > > : So, the big question is whether there is anything we can tune to > speed up > :the writes. The freebsd machines are NFS clients to the sun servers doing > :most of the web processing. Overall performance on the reads seems to be > :best with nfs v3 over udp, which is what I'm using now. All of the web > :server directories are soft mounted directly, with no amd currently in use. > : > :thanks, > : > :Doug > > Well, NFS buffers are usually sent over the network the moment they > are full. If you are not running any nfsiod's I should have mentioned, I have 20 nfsiod's running. I started so many initially to help in the stress testing I was doing, but I left them running because the servers are handling from 2-4 requests per second and we have lots of ram in the boxes. Is there a way to figure out how many are getting used concurrently, or is too many not a problem? Thanks, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
FYI [ymiron...@earthlink.net: C-Forge for FreeBSD]
- Forwarded message from "Yuri Mironoff" - Reply-To: "Yuri Mironoff" From: "Yuri Mironoff" To: Subject: C-Forge for FreeBSD Date: Sun, 8 Aug 1999 22:42:50 -0400 Hello, We're recently ported the C-Forge Integrated Development Environment to FreeBSD (short description of product follows). Please add us to your list of commercial software vendors. Thank you very much in advance, Yuri Mironoff Code Forge, Inc http://www.codeforge.com C-Forge (pronounced Code Forge) is a multi-user integrated development environment that provides full project management and complete edit/compile/debug cycle support. Features include complete abstraction of the "makefile" concept, a Project Manager for Visual presentation of project structure and component status using a dependency tree and a separate "desktop" area showing work in progress, support for C/C++, Perl, Oracle ProC/C++, Tcl, PHP, Java, Javascript, Python, Qt, Pascal, Free Pascal, FORTRAN, TeX/LaTeX, SGML, Modula-2 and Assembler, integrated revision control, fully configurable programmer's editor and much more. Evaluation version available for download. Please visit us at http://www.codeforge.com - End forwarded message - -- Wolfram Schneider http://wolfram.schneider.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Fix/tuning to improve slow NFS writes?
On Mon, 9 Aug 1999, Doug wrote: > Matthew Dillon wrote: > > > > : So, the big question is whether there is anything we can tune to > > speed up > > :the writes. The freebsd machines are NFS clients to the sun servers doing > > :most of the web processing. Overall performance on the reads seems to be > > :best with nfs v3 over udp, which is what I'm using now. All of the web > > :server directories are soft mounted directly, with no amd currently in use. > > : > > :thanks, > > : > > :Doug > > > > Well, NFS buffers are usually sent over the network the moment they > > are full. If you are not running any nfsiod's > > I should have mentioned, I have 20 nfsiod's running. I started so many > initially to help in the stress testing I was doing, but I left them > running because the servers are handling from 2-4 requests per second and > we have lots of ram in the boxes. Is there a way to figure out how many are > getting used concurrently, or is too many not a problem? ? You need to run 'nfsd' on the servers, not nfsiod. nfsd - run on server nfsiod - run on client nfsd takes the same -n arg for the number to start. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Fix/tuning to improve slow NFS writes?
On Mon, Aug 09, 1999 at 04:50:51AM -0400, Alfred Perlstein wrote: > On Mon, 9 Aug 1999, Doug wrote: > > > Matthew Dillon wrote: > > > > > > : So, the big question is whether there is anything we can tune to > > > speed up > > > :the writes. The freebsd machines are NFS clients to the sun servers doing > > > :most of the web processing. Overall performance on the reads seems to be > > > :best with nfs v3 over udp, which is what I'm using now. All of the web > > > :server directories are soft mounted directly, with no amd currently in > > > use. Could tuning any of the NFS options in the kernel help? Matt, could you give any tips? > > I should have mentioned, I have 20 nfsiod's running. I started so many > > initially to help in the stress testing I was doing, but I left them > > running because the servers are handling from 2-4 requests per second and > > we have lots of ram in the boxes. Is there a way to figure out how many are > > getting used concurrently, or is too many not a problem? > > You need to run 'nfsd' on the servers, not nfsiod. > > nfsd - run on server > nfsiod - run on client He's talking about the client boxes, just measuring from the server side. Reference the second sentence at top. Greg -- Gregory S. Sutter Failing sardine factory cans employees! mailto:gsut...@pobox.com http://www.pobox.com/~gsutter/ PGP DSS public key 0x40AE3052 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
"Brian F. Feldman" wrote: > >Is there anyone who is specifically checking for long long >C9X-compliancy in the source tree (mainly libc)? I started reviewing libc for C9X features in general -- a fair amount of work is required to update macros and typedefs in (plus the new ). Doing a thorough job is difficult because C9X is somewhat gratuitously incompatible with gnu C (e.g. the spelling of __complex__, zero-length arrays in structures, macro varargs, etc.) and gnu C doesn't yet support restrict. 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.
Dan Moschuk wrote: > >After quite an exhausting night (of all the ways I didn't want to spend my >Sunday...) I've managed to track down a problem that has been frustrating me >all night. The problem exists with multiple threads calling gethostbyaddr() >(not necessarily at the same time). src/lib/libc/net/gethostbydns.c seems to use a load of static variables in a non-thread-safe fashion. 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.
| >After quite an exhausting night (of all the ways I didn't want to spend my | >Sunday...) I've managed to track down a problem that has been frustrating me | >all night. The problem exists with multiple threads calling gethostbyaddr() | >(not necessarily at the same time). | | src/lib/libc/net/gethostbydns.c seems to use a load of static | variables in a non-thread-safe fashion. Yes, I noticed that as well. I also noticed that gethostbyaddr_r worked "less" than gethostbyaddr did (the result was that all threads ended up thrashing each other, and not of them continued on). I was going to use res_query, but noticed that it too used static buffers (although it looks pretty easy to fix). Would anyone be offended if I were to produce a few patches to fix up these routines once and for all? Should I just produce a few #ifdef _THREAD_SAFEs or try full blown routines (gethostbyaddr_r, res_query_r)? Thanks, Dan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Fix/tuning to improve slow NFS writes?
Alfred Perlstein wrote: > > On Mon, 9 Aug 1999, Doug wrote: > > > Matthew Dillon wrote: > > > > > > : So, the big question is whether there is anything we can tune to > > > speed up > > > :the writes. The freebsd machines are NFS clients to the sun servers doing > > > :most of the web processing. Overall performance on the reads seems to be > > > :best with nfs v3 over udp, which is what I'm using now. All of the web > > > :server directories are soft mounted directly, with no amd currently in > > > use. > > > : > > > :thanks, > > > : > > > :Doug > > > > > > Well, NFS buffers are usually sent over the network the moment they > > > are full. If you are not running any nfsiod's > > > > I should have mentioned, I have 20 nfsiod's running. I started so many > > initially to help in the stress testing I was doing, but I left them > > running because the servers are handling from 2-4 requests per second and > > we have lots of ram in the boxes. Is there a way to figure out how many are > > getting used concurrently, or is too many not a problem? > > ? > > You need to run 'nfsd' on the servers, not nfsiod. Sorry I wasn't clear. That's what I get for writing posts like this when I'm tired. In that paragraph "servers" refers to the freebsd cgi/web servers that are acting as NFS clients to the sun boxes. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Fix/tuning to improve slow NFS writes?
: I should have mentioned, I have 20 nfsiod's running. I started so many :initially to help in the stress testing I was doing, but I left them :running because the servers are handling from 2-4 requests per second and :we have lots of ram in the boxes. Is there a way to figure out how many are :getting used concurrently, or is too many not a problem? : :Thanks, : :Doug You can look at their cpu utilization with ps. You should see high cpu use on a couple of them and then tapering off. The system allocates nfsiods in order depending on the number of outstanding asynchronous requests. If the web server is not bound by write bandwidth, it could be getting bound up in NFS stat calls. I think what you need to do at this point is run ktrace on some of the web server processes to see where the performance bottlenecks are. Let ktrace collect statistics for a while and then make sure to turn it off with 'ktrace -C', and then use 'kdump -R | less' to see the results. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Mon, 9 Aug 1999, Tony Finch wrote:
> "Brian F. Feldman" wrote:
> >
> >Is there anyone who is specifically checking for long long
> >C9X-compliancy in the source tree (mainly libc)?
>
> I started reviewing libc for C9X features in general -- a fair amount
> of work is required to update macros and typedefs in
> (plus the new ).
Shall we work on it, then?
>
> Doing a thorough job is difficult because C9X is somewhat gratuitously
> incompatible with gnu C (e.g. the spelling of __complex__, zero-length
> arrays in structures, macro varargs, etc.) and gnu C doesn't yet
> support restrict.
But GNU has officially stated that they will fully support C9X, and
they've started already. For instance, int *a = ((int [4]){1,2,3,4});
should work now, according to the infopages. Eventually, I'd be certain
that GNU would rather be compliant with C9X than with GNU C.
>
> Tony.
> --
> f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix
>
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
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: > > | >After quite an exhausting night (of all the ways I didn't want to spend my > | >Sunday...) I've managed to track down a problem that has been frustrating > me > | >all night. The problem exists with multiple threads calling > gethostbyaddr() > | >(not necessarily at the same time). > | > | src/lib/libc/net/gethostbydns.c seems to use a load of static > | variables in a non-thread-safe fashion. > > Yes, I noticed that as well. I also noticed that gethostbyaddr_r worked > "less" than gethostbyaddr did (the result was that all threads ended up > thrashing each other, and not of them continued on). I was going to use > res_query, but noticed that it too used static buffers (although it looks > pretty easy to fix). > > Would anyone be offended if I were to produce a few patches to fix up these > routines once and for all? Should I just produce a few #ifdef _THREAD_SAFEs > or try full blown routines (gethostbyaddr_r, res_query_r)? This is the second request for gethostbyaddr_r I've seen this week. I've been (oh so slowly) implementing the missing _r routines in our library and documenting the hidden ones I've already found. This is one of the uglier ones. Hacking up the mess we've got would be a waste of time, IMHO. If you're going to do it, go all the way and make a CLEAN implementation of the _r routines and then implement the non _r routines on top of them. If you need prototypes, email back and I'll find the ones you want to work on first. When you're done, send me files or diffs and I'll be very happy to test them for you. I'll even help with the man pages. -- "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
fetchGetURL() (fwd)
I can't seem to get libfetch to properly link in. I've tinkered with the order to no avail & don't see what I'm missing. cc -O2 -pipe -g -o importquotes importquotes.o -L/usr/local/lib/mysql -lmysqlclient -lfetch -lcom_err -lstdc++ importquotes.o: In function `main': /usr/local/stock/importquotes.cpp(.text+0x217): undefined reference to `fetchGetURL(char *, char *)' *** Error code 1 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
[snip] 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 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---Brian McGovern said: > [snip] > > 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 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
this is solved by one of two methods: 1-) require the caller of gethostbyaddr() to supply a pointer to a hostent struct which will be filled. or 2-) the library uses thread specific storage which is re-used in each call. From: Joe Groff Reply-To: og...@humboldt1.com To: bmcgo...@cisco.com CC: d...@trinsec.com, hack...@freebsd.org Subject: Re: gethostbyaddr() and threads. Date: Mon, 9 Aug 1999 14:21:38 -0700 (PDT) MIME-Version: 1.0 From owner-freebsd-hack...@freebsd.org Mon Aug 9 14:22:43 1999 Received: by hub.freebsd.org (Postfix, from userid 538)id 13F1E152DC; Mon, 9 Aug 1999 14:24:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1])by hub.freebsd.org (Postfix) with SMTPid F31551CD65D; Mon, 9 Aug 1999 14:24:35 -0700 (PDT)(envelope-from owner-freebsd-hackers) Received: by hub.freebsd.org (bulk_mailer v1.12); Mon, 9 Aug 1999 14:24:35 -0700 Delivered-To: freebsd-hackers@freebsd.org Received: from home.humboldt1.com (home.humboldt1.com [206.13.45.1])by hub.freebsd.org (Postfix) with ESMTP id 9598214D75for ; Mon, 9 Aug 1999 14:24:29 -0700 (PDT)(envelope-from og...@humboldt1.com) Received: from shovel.groff (ppp176-pm5.humboldt1.com [207.104.21.169])by home.humboldt1.com (Pro-8.9.2/Pro-8.9.2) with SMTP id OAA21266;Mon, 9 Aug 1999 14:21:38 -0700 (PDT) Message-Id: <199908092121.oaa21...@home.humboldt1.com> In-Reply-To: <199908092104.raa06...@bmcgover-pc.cisco.com> X-Mailer: XCmail 1.0.0 - with PGP support, PGP engine version 0.5 (FreeBSD) X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/ Sender: owner-freebsd-hack...@freebsd.org X-Loop: FreeBSD.ORG Precedence: bulk ---Brian McGovern said: > [snip] > > 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 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message ___ Get Free Email and Do More On The Web. Visit http://www.msn.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---Steve Tarkalson said: > this is solved by one of two methods: >1-) require the caller of gethostbyaddr() to supply a pointer to >a hostent struct which will be filled. > or 2-) the library uses thread specific storage which is re-used in >each call. > You could malloc() a struct hostent for each call to gethostby*(), each time registering the hostent in some list along with the thread's PID. If the same thread calls gethostby*, use the same buffer, or allocate a new one if another thread calls it. Have a static function be called atexit to free all the mallocs. -Joe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> ---Steve Tarkalson said: > > this is solved by one of two methods: > >1-) require the caller of gethostbyaddr() to supply a pointer to > >a hostent struct which will be filled. > > or 2-) the library uses thread specific storage which is re-used in > >each call. > > > You could malloc() a struct hostent for each call to > gethostby*(), each time registering the hostent in some list along with the > thread's PID. If the same thread calls gethostby*, use the same buffer, or > allocate a new one if another thread calls it. Have a static function be > called > atexit to free all the mallocs. Yuk! If you're writing a multithreaded program, a slightly different API for gethostbyname() is likely to be the least of your worries. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---Louis A. Mamakos said: >> You could malloc() a struct hostent for each call to >> gethostby*(), each time registering the hostent in some list along with the >> thread's PID. If the same thread calls gethostby*, use the same buffer, or >> allocate a new one if another thread calls it. Have a static function be > called >> atexit to free all the mallocs. > > Yuk! > > If you're writing a multithreaded program, a slightly different API for > gethostbyname() is likely to be the least of your worries. > 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? -Joe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> > ---Steve Tarkalson said: > > > this is solved by one of two methods: > > >1-) require the caller of gethostbyaddr() to supply a pointer to > > >a hostent struct which will be filled. > > > or 2-) the library uses thread specific storage which is re-used in > > >each call. > > > > > You could malloc() a struct hostent for each call to > > gethostby*(), each time registering the hostent in some list along with the > > thread's PID. If the same thread calls gethostby*, use the same buffer, or > > allocate a new one if another thread calls it. Have a static function be > > called > > atexit to free all the mallocs. > > Yuk! > > If you're writing a multithreaded program, a slightly different API for > gethostbyname() is likely to be the least of your worries. Agreed. gethostbyname_r() on solaris requires the caller to provide the address to write into, which is IMO the correct solution. Yes, it's a different API. But, the other alternatives are worse. The user must be able to control his memory allocation. For example, in a typical networking application, gethostbyname() could be called thousands or millions of times, and allocating memory everytime that can't be cleaned up until the program exits is completely unacceptable. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---Louis A. Mamakos said: >> ---Steve Tarkalson said: >> > this is solved by one of two methods: >> >1-) require the caller of gethostbyaddr() to supply a pointer to >> >a hostent struct which will be filled. >> > or 2-) the library uses thread specific storage which is re-used in >> >each call. >> > >> You could malloc() a struct hostent for each call to >> gethostby*(), each time registering the hostent in some list along with the >> thread's PID. If the same thread calls gethostby*, use the same buffer, or >> allocate a new one if another thread calls it. Have a static function be > called >> atexit to free all the mallocs. > > Yuk! > > If you're writing a multithreaded program, a slightly different API for > gethostbyname() is likely to be the least of your worries. > 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 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
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.
Re: gethostbyaddr() and threads.
---Dan Moschuk said: > > | 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. That's what I meant by an API change. Sorry for not being clearer. However, if you can roll in reentrancy without having to add the _r functions, that would save some sweat on the programmers' side. >>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. > Go for it! Someone needs to. :) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
New kernel drivers
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? Thanks! -Joe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Configuration mechanism of PCI bus
Even with "PCI System Architecture, 4th edition" at hand, I still have some problems understanding the code in isa/pcibus.c. Please point out any misunderstanding I may have in the following: (1) At first, you can not modify the address port at 0xcf8 without a FULL 32-bit write. The routine pci_cfgopen() seems to use this fact. (2) The constant CONF1_ENABLE_MSK includes 4 higher bus number bits, only 4 bits can be used as bus number, so we can have at most 16 PCI buses. (3) The variable "mode1res" seems to refer to any residual left by BIOS in the address port. If it is non-zero, we will try to find a device using configuration mechanism 1. (3) The magic constant 0xf870ff excludes many devices. How it is chosen? I guess those excluded devices are not important or supported by FreeBSD. It seems to me that if pci_cfgcheck() finds at least one device, then the configuration mechanism is regarded as correctly detected. Any help is appreciated. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd-hackers-digest V4 #576
> > I believe the joystick driver in FreeBSD could probably be redone, to support > all the non-standard joysticks that many people (like me :) have. Having > just recently converted to FreeBSD from Linux, though, I don't know the best > way to go about it. Here are some ideas (sorry if my terminology is wrong): > > (1) Redefine the core joystick code as a controller, and then have all the > different joystick types ride on top of it, like: > > controller joy0at isa? port IO_GAME # Serves joystick port 0x201 > #device jan0at joy0 # Analog joystick > device jgpp0 at joy0 # Gravis GamePad Pro > etc... > This would also allow for modules to be used for all the different > joystick > types, I think. > > (2) Have a monolithic joystick driver, with options to pick the proper type: > > device joy0at isa? port IO_GAME # Just like it is now > options JOY_ANALOG > options JOY_GRAVIS > etc... > > I also believe it should use the Linux joystick's device interface, so that > folks that have already written their games to use the Linux joysticks can > work > in FreeBSD with minor effort. > > Any help or comments are appreciated. > I'm partway through porting Vojtech's Linux joystick code to FreeBSD, as a series of loadable modules. There is the main module (which is mostly converted, although some of the Linuxisms are a bit hard to come up with an equivalent to, even with the Linux device drivers book) and a seperate module for each of the different hardware devices. You'll kldload the main module first, then the device specific module, which'll call a joystick registration routine to make itself known. You've just spurred me into action and I hope to get the main module finished this weekend. The recent chatter about allowing kldload to give modules arguments is very interesting, as it would allow one to specify port addresses and the like. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd-hackers-digest V4 #576
On Tue, 10 Aug 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > > > > > I believe the joystick driver in FreeBSD could probably be redone, to > > support > > all the non-standard joysticks that many people (like me :) have. Having > > just recently converted to FreeBSD from Linux, though, I don't know the best > > way to go about it. Here are some ideas (sorry if my terminology is wrong): > > > > (1) Redefine the core joystick code as a controller, and then have all the > > different joystick types ride on top of it, like: > > > > controller joy0at isa? port IO_GAME # Serves joystick port 0x201 > > #device jan0at joy0 # Analog joystick > > device jgpp0 at joy0 # Gravis GamePad Pro > > etc... > > This would also allow for modules to be used for all the different > > joystick > > types, I think. > > > > (2) Have a monolithic joystick driver, with options to pick the proper type: > > > > device joy0at isa? port IO_GAME # Just like it is now > > options JOY_ANALOG > > options JOY_GRAVIS > > etc... > > > > I also believe it should use the Linux joystick's device interface, so that > > folks that have already written their games to use the Linux joysticks can > > work > > in FreeBSD with minor effort. > > > > Any help or comments are appreciated. > > > > I'm partway through porting Vojtech's Linux joystick code to FreeBSD, as a > series of loadable modules. There is the main module (which is mostly > converted, although some of the Linuxisms are a bit hard to come up with an > equivalent to, even with the Linux device drivers book) and a seperate module > for each of the different hardware devices. You'll kldload the main module > first, then the device specific module, which'll call a joystick registration > routine to make itself known. You've just spurred me into action and I hope > to > get the main module finished this weekend. > > The recent chatter about allowing kldload to give modules arguments is very > interesting, as it would allow one to specify port addresses and the like. > > Stephen Well, I was going to try to roll my own for this, but it's always nice to know someone's already done it for me. :) I'm gone though for the next couple weeks though, so that'll be a nice thing to get back home to. Many thanks! Where will I be able to get it? -Joe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd-hackers-digest V4 #576
Stephen Hocking wrote: > The recent chatter about allowing kldload to give modules arguments is very > interesting, as it would allow one to specify port addresses and the like. Would it be useful to be able to be able to do something like this: kldload -t kernel_config /sys/i386/conf/YOURKERNELNAME ... and have drivers consult the information they find in there for config hints? If newbus knew how to reconstruct config_devtab at runtime by parsing a "kernel_config" module's "device" and "controller" lines, we'd get dynamic runtime reconfiguration for free. It could even defer the initial construction of config_devtab until boot-time if you used "options INCLUDE_CONFIG_FILE" to provide default configuration data... - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd-hackers-digest V4 #576
> > Stephen > Well, I was going to try to roll my own for this, but it's always nice to > know someone's already done it for me. :) I'm gone though for the next > couple weeks though, so that'll be a nice thing to get back home to. Many > thanks! > > Where will I be able to get it? > > -Joe > Well, it's not ready yet. I'll be putting it in as a PR once I've finished. Probably it'll be released to the multimedia group first as a test. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
Joe Groff wrote: > > ---Louis A. Mamakos said: > >> You could malloc() a struct hostent for each call to > >> gethostby*(), each time registering the hostent in some list along with the > >> thread's PID. If the same thread calls gethostby*, use the same buffer, or > >> allocate a new one if another thread calls it. Have a static function be > > called > >> atexit to free all the mallocs. > > > > Yuk! > > > > If you're writing a multithreaded program, a slightly different API for > > gethostbyname() is likely to be the least of your worries. > > > 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. -- "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.
Joe Groff wrote: > > ---Dan Moschuk said: > > > > | 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. > That's what I meant by an API change. Sorry for not being clearer. > However, if you can roll in reentrancy without having to add the _r > functions, that would save some sweat on the programmers' side. No, it wouldn't, because any existing programs that already handle name server queries within threads will already use the gethostby*_r APIs. > >>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. > > > Go for it! Someone needs to. :) Here are the prototypes. Hosts: #include #include #include #include #include struct hostent *gethostbyname_r(const char *name, struct hostent *result, char *buffer, int buflen, int *h_errnop); struct hostent *gethostbyaddr_r(const char *addr, int length, int type, struct hostent *result, char *buffer, int buflen, int *h_errnop); struct hostent *gethostent_r(struct hostent *result, char *buffer, int buflen, int *h_errnop); Nets: #include struct netent *getnetbyname_r(const char *name, struct netent *result, char *buffer, int buflen); struct netent *getnetbyaddr_r(long net, int type, struct netent *result, char *buffer, int buflen); struct netent *getnetent_r(struct netent *result, char *buffer, int buflen); Protocols: #include struct protoent *getprotobyname_r(const char *name, struct protoent *result, char *buffer, int buflen); struct protoent *getprotobynumber_r(int proto, struct protoent *result, char *buffer, int buflen); struct protoent *getprotoent_r(struct protoent *result, char *buffer, int buflen); Services: #include struct servent *getservbyname_r(const char *name, const char *proto, struct servent *result, char *buffer, int buflen); struct servent *getservbyport_r(int port, const char *proto, struct servent *result, char *buffer, int buflen); struct servent *getservent_r(struct servent *result, char *buffer, int buflen); RPC services: #include struct rpcent *getrpcbyname_r(const char * name, struct rpcent *result, char *buffer, int buflen); struct rpcent *getrpcbynumber_r(const int number, struct rpcent *result, char *buffer, int buflen); struct rpcent *getrpcent_r(struct rpcent *result, char *buffer, int buflen); Any questions? -- "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 Mon, 9 Aug 1999, Wes Peters wrote: > Here are the prototypes. Hosts: > > #include > #include > #include > #include > #include > > struct hostent *gethostbyname_r(const char *name, > struct hostent *result, char *buffer, int buflen, > int *h_errnop); > > struct hostent *gethostbyaddr_r(const char *addr, > int length, int type, struct hostent *result, > char *buffer, int buflen, int *h_errnop); > > struct hostent *gethostent_r(struct hostent *result, > char *buffer, int buflen, int *h_errnop); > > Nets: > > #include > > struct netent *getnetbyname_r(const char *name, > struct netent *result, char *buffer, int buflen); > > struct netent *getnetbyaddr_r(long net, int type, > struct netent *result, char *buffer, int buflen); > > struct netent *getnetent_r(struct netent *result, > char *buffer, int buflen); > > Protocols: > > #include > > struct protoent *getprotobyname_r(const char *name, > struct protoent *result, char *buffer, int buflen); > > struct protoent *getprotobynumber_r(int proto, > struct protoent *result, char *buffer, int buflen); > > struct protoent *getprotoent_r(struct protoent *result, > char *buffer, int buflen); > > Services: > > #include > > struct servent *getservbyname_r(const char *name, > const char *proto, struct servent *result, > char *buffer, int buflen); > > struct servent *getservbyport_r(int port, const char *proto, > struct servent *result, char *buffer, int buflen); > > struct servent *getservent_r(struct servent *result, > char *buffer, int buflen); > > RPC services: > > #include > > struct rpcent *getrpcbyname_r(const char * name, > struct rpcent *result, char *buffer, int buflen); > > struct rpcent *getrpcbynumber_r(const int number, > struct rpcent *result, char *buffer, int buflen); > > 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. -Joe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: New kernel drivers
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. eT To Unsubscribe: send mail to majord...@freebsd.org 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
FYI [ymironoff@earthlink.net: C-Forge for FreeBSD]
- Forwarded message from "Yuri Mironoff" <[EMAIL PROTECTED]> - Reply-To: "Yuri Mironoff" <[EMAIL PROTECTED]> From: "Yuri Mironoff" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: C-Forge for FreeBSD Date: Sun, 8 Aug 1999 22:42:50 -0400 Hello, We're recently ported the C-Forge Integrated Development Environment to FreeBSD (short description of product follows). Please add us to your list of commercial software vendors. Thank you very much in advance, Yuri Mironoff Code Forge, Inc http://www.codeforge.com C-Forge (pronounced Code Forge) is a multi-user integrated development environment that provides full project management and complete edit/compile/debug cycle support. Features include complete abstraction of the "makefile" concept, a Project Manager for Visual presentation of project structure and component status using a dependency tree and a separate "desktop" area showing work in progress, support for C/C++, Perl, Oracle ProC/C++, Tcl, PHP, Java, Javascript, Python, Qt, Pascal, Free Pascal, FORTRAN, TeX/LaTeX, SGML, Modula-2 and Assembler, integrated revision control, fully configurable programmer's editor and much more. Evaluation version available for download. Please visit us at http://www.codeforge.com - End forwarded message - -- Wolfram Schneider <[EMAIL PROTECTED]> http://wolfram.schneider.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fix/tuning to improve slow NFS writes?
On Mon, 9 Aug 1999, Doug wrote: > Matthew Dillon wrote: > > > > : So, the big question is whether there is anything we can tune to speed up > > :the writes. The freebsd machines are NFS clients to the sun servers doing > > :most of the web processing. Overall performance on the reads seems to be > > :best with nfs v3 over udp, which is what I'm using now. All of the web > > :server directories are soft mounted directly, with no amd currently in use. > > : > > :thanks, > > : > > :Doug > > > > Well, NFS buffers are usually sent over the network the moment they > > are full. If you are not running any nfsiod's > > I should have mentioned, I have 20 nfsiod's running. I started so many > initially to help in the stress testing I was doing, but I left them > running because the servers are handling from 2-4 requests per second and > we have lots of ram in the boxes. Is there a way to figure out how many are > getting used concurrently, or is too many not a problem? ? You need to run 'nfsd' on the servers, not nfsiod. nfsd - run on server nfsiod - run on client nfsd takes the same -n arg for the number to start. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fix/tuning to improve slow NFS writes?
On Mon, Aug 09, 1999 at 04:50:51AM -0400, Alfred Perlstein wrote: > On Mon, 9 Aug 1999, Doug wrote: > > > Matthew Dillon wrote: > > > > > > : So, the big question is whether there is anything we can tune to speed up > > > :the writes. The freebsd machines are NFS clients to the sun servers doing > > > :most of the web processing. Overall performance on the reads seems to be > > > :best with nfs v3 over udp, which is what I'm using now. All of the web > > > :server directories are soft mounted directly, with no amd currently in use. Could tuning any of the NFS options in the kernel help? Matt, could you give any tips? > > I should have mentioned, I have 20 nfsiod's running. I started so many > > initially to help in the stress testing I was doing, but I left them > > running because the servers are handling from 2-4 requests per second and > > we have lots of ram in the boxes. Is there a way to figure out how many are > > getting used concurrently, or is too many not a problem? > > You need to run 'nfsd' on the servers, not nfsiod. > > nfsd - run on server > nfsiod - run on client He's talking about the client boxes, just measuring from the server side. Reference the second sentence at top. Greg -- Gregory S. Sutter Failing sardine factory cans employees! mailto:[EMAIL PROTECTED] http://www.pobox.com/~gsutter/ PGP DSS public key 0x40AE3052 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
"Brian F. Feldman" <[EMAIL PROTECTED]> wrote: > >Is there anyone who is specifically checking for long long >C9X-compliancy in the source tree (mainly libc)? I started reviewing libc for C9X features in general -- a fair amount of work is required to update macros and typedefs in (plus the new ). Doing a thorough job is difficult because C9X is somewhat gratuitously incompatible with gnu C (e.g. the spelling of __complex__, zero-length arrays in structures, macro varargs, etc.) and gnu C doesn't yet support restrict. 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.
Dan Moschuk <[EMAIL PROTECTED]> wrote: > >After quite an exhausting night (of all the ways I didn't want to spend my >Sunday...) I've managed to track down a problem that has been frustrating me >all night. The problem exists with multiple threads calling gethostbyaddr() >(not necessarily at the same time). src/lib/libc/net/gethostbydns.c seems to use a load of static variables in a non-thread-safe fashion. 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.
| >After quite an exhausting night (of all the ways I didn't want to spend my | >Sunday...) I've managed to track down a problem that has been frustrating me | >all night. The problem exists with multiple threads calling gethostbyaddr() | >(not necessarily at the same time). | | src/lib/libc/net/gethostbydns.c seems to use a load of static | variables in a non-thread-safe fashion. Yes, I noticed that as well. I also noticed that gethostbyaddr_r worked "less" than gethostbyaddr did (the result was that all threads ended up thrashing each other, and not of them continued on). I was going to use res_query, but noticed that it too used static buffers (although it looks pretty easy to fix). Would anyone be offended if I were to produce a few patches to fix up these routines once and for all? Should I just produce a few #ifdef _THREAD_SAFEs or try full blown routines (gethostbyaddr_r, res_query_r)? Thanks, Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fix/tuning to improve slow NFS writes?
Alfred Perlstein wrote: > > On Mon, 9 Aug 1999, Doug wrote: > > > Matthew Dillon wrote: > > > > > > : So, the big question is whether there is anything we can tune to speed up > > > :the writes. The freebsd machines are NFS clients to the sun servers doing > > > :most of the web processing. Overall performance on the reads seems to be > > > :best with nfs v3 over udp, which is what I'm using now. All of the web > > > :server directories are soft mounted directly, with no amd currently in use. > > > : > > > :thanks, > > > : > > > :Doug > > > > > > Well, NFS buffers are usually sent over the network the moment they > > > are full. If you are not running any nfsiod's > > > > I should have mentioned, I have 20 nfsiod's running. I started so many > > initially to help in the stress testing I was doing, but I left them > > running because the servers are handling from 2-4 requests per second and > > we have lots of ram in the boxes. Is there a way to figure out how many are > > getting used concurrently, or is too many not a problem? > > ? > > You need to run 'nfsd' on the servers, not nfsiod. Sorry I wasn't clear. That's what I get for writing posts like this when I'm tired. In that paragraph "servers" refers to the freebsd cgi/web servers that are acting as NFS clients to the sun boxes. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fix/tuning to improve slow NFS writes?
: I should have mentioned, I have 20 nfsiod's running. I started so many :initially to help in the stress testing I was doing, but I left them :running because the servers are handling from 2-4 requests per second and :we have lots of ram in the boxes. Is there a way to figure out how many are :getting used concurrently, or is too many not a problem? : :Thanks, : :Doug You can look at their cpu utilization with ps. You should see high cpu use on a couple of them and then tapering off. The system allocates nfsiods in order depending on the number of outstanding asynchronous requests. If the web server is not bound by write bandwidth, it could be getting bound up in NFS stat calls. I think what you need to do at this point is run ktrace on some of the web server processes to see where the performance bottlenecks are. Let ktrace collect statistics for a while and then make sure to turn it off with 'ktrace -C', and then use 'kdump -R | less' to see the results. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Mon, 9 Aug 1999, Tony Finch wrote:
> "Brian F. Feldman" <[EMAIL PROTECTED]> wrote:
> >
> >Is there anyone who is specifically checking for long long
> >C9X-compliancy in the source tree (mainly libc)?
>
> I started reviewing libc for C9X features in general -- a fair amount
> of work is required to update macros and typedefs in
> (plus the new ).
Shall we work on it, then?
>
> Doing a thorough job is difficult because C9X is somewhat gratuitously
> incompatible with gnu C (e.g. the spelling of __complex__, zero-length
> arrays in structures, macro varargs, etc.) and gnu C doesn't yet
> support restrict.
But GNU has officially stated that they will fully support C9X, and
they've started already. For instance, int *a = ((int [4]){1,2,3,4});
should work now, according to the infopages. Eventually, I'd be certain
that GNU would rather be compliant with C9X than with GNU C.
>
> Tony.
> --
> f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix
>
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
Dan Moschuk wrote: > > | >After quite an exhausting night (of all the ways I didn't want to spend my > | >Sunday...) I've managed to track down a problem that has been frustrating me > | >all night. The problem exists with multiple threads calling gethostbyaddr() > | >(not necessarily at the same time). > | > | src/lib/libc/net/gethostbydns.c seems to use a load of static > | variables in a non-thread-safe fashion. > > Yes, I noticed that as well. I also noticed that gethostbyaddr_r worked > "less" than gethostbyaddr did (the result was that all threads ended up > thrashing each other, and not of them continued on). I was going to use > res_query, but noticed that it too used static buffers (although it looks > pretty easy to fix). > > Would anyone be offended if I were to produce a few patches to fix up these > routines once and for all? Should I just produce a few #ifdef _THREAD_SAFEs > or try full blown routines (gethostbyaddr_r, res_query_r)? This is the second request for gethostbyaddr_r I've seen this week. I've been (oh so slowly) implementing the missing _r routines in our library and documenting the hidden ones I've already found. This is one of the uglier ones. Hacking up the mess we've got would be a waste of time, IMHO. If you're going to do it, go all the way and make a CLEAN implementation of the _r routines and then implement the non _r routines on top of them. If you need prototypes, email back and I'll find the ones you want to work on first. When you're done, send me files or diffs and I'll be very happy to test them for you. I'll even help with the man pages. -- "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
fetchGetURL() (fwd)
I can't seem to get libfetch to properly link in. I've tinkered with the order to no avail & don't see what I'm missing. cc -O2 -pipe -g -o importquotes importquotes.o -L/usr/local/lib/mysql -lmysqlclient -lfetch -lcom_err -lstdc++ importquotes.o: In function `main': /usr/local/stock/importquotes.cpp(.text+0x217): undefined reference to `fetchGetURL(char *, char *)' *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
[snip] 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---Brian McGovern said: > [snip] > > 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
this is solved by one of two methods: 1-) require the caller of gethostbyaddr() to supply a pointer to a hostent struct which will be filled. or 2-) the library uses thread specific storage which is re-used in each call. >From: Joe Groff <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >CC: [EMAIL PROTECTED], [EMAIL PROTECTED] >Subject: Re: gethostbyaddr() and threads. >Date: Mon, 9 Aug 1999 14:21:38 -0700 (PDT) >MIME-Version: 1.0 >From [EMAIL PROTECTED] Mon Aug 9 14:22:43 1999 >Received: by hub.freebsd.org (Postfix, from userid 538)id 13F1E152DC; Mon, >9 Aug 1999 14:24:36 -0700 (PDT) >Received: from localhost (localhost [127.0.0.1])by hub.freebsd.org >(Postfix) with SMTPid F31551CD65D; Mon, 9 Aug 1999 14:24:35 -0700 >(PDT)(envelope-from owner-freebsd-hackers) >Received: by hub.freebsd.org (bulk_mailer v1.12); Mon, 9 Aug 1999 14:24:35 >-0700 >Delivered-To: [EMAIL PROTECTED] >Received: from home.humboldt1.com (home.humboldt1.com [206.13.45.1])by >hub.freebsd.org (Postfix) with ESMTP id 9598214D75for ><[EMAIL PROTECTED]>; Mon, 9 Aug 1999 14:24:29 -0700 (PDT)(envelope-from >[EMAIL PROTECTED]) >Received: from shovel.groff (ppp176-pm5.humboldt1.com [207.104.21.169])by >home.humboldt1.com (Pro-8.9.2/Pro-8.9.2) with SMTP id OAA21266;Mon, 9 Aug >1999 14:21:38 -0700 (PDT) >Message-Id: <[EMAIL PROTECTED]> >In-Reply-To: <[EMAIL PROTECTED]> >X-Mailer: XCmail 1.0.0 - with PGP support, PGP engine version 0.5 (FreeBSD) >X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/ >Sender: [EMAIL PROTECTED] >X-Loop: FreeBSD.ORG >Precedence: bulk > >---Brian McGovern said: > > [snip] > > > > 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 > > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-hackers" in the body of the message > ___ Get Free Email and Do More On The Web. Visit http://www.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---Steve Tarkalson said: > this is solved by one of two methods: >1-) require the caller of gethostbyaddr() to supply a pointer to >a hostent struct which will be filled. > or 2-) the library uses thread specific storage which is re-used in >each call. > You could malloc() a struct hostent for each call to gethostby*(), each time registering the hostent in some list along with the thread's PID. If the same thread calls gethostby*, use the same buffer, or allocate a new one if another thread calls it. Have a static function be called atexit to free all the mallocs. -Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> ---Steve Tarkalson said: > > this is solved by one of two methods: > >1-) require the caller of gethostbyaddr() to supply a pointer to > >a hostent struct which will be filled. > > or 2-) the library uses thread specific storage which is re-used in > >each call. > > > You could malloc() a struct hostent for each call to > gethostby*(), each time registering the hostent in some list along with the > thread's PID. If the same thread calls gethostby*, use the same buffer, or > allocate a new one if another thread calls it. Have a static function be called > atexit to free all the mallocs. Yuk! If you're writing a multithreaded program, a slightly different API for gethostbyname() is likely to be the least of your worries. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---Louis A. Mamakos said: >> You could malloc() a struct hostent for each call to >> gethostby*(), each time registering the hostent in some list along with the >> thread's PID. If the same thread calls gethostby*, use the same buffer, or >> allocate a new one if another thread calls it. Have a static function be > called >> atexit to free all the mallocs. > > Yuk! > > If you're writing a multithreaded program, a slightly different API for > gethostbyname() is likely to be the least of your worries. > 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? -Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> > ---Steve Tarkalson said: > > > this is solved by one of two methods: > > >1-) require the caller of gethostbyaddr() to supply a pointer to > > >a hostent struct which will be filled. > > > or 2-) the library uses thread specific storage which is re-used in > > >each call. > > > > > You could malloc() a struct hostent for each call to > > gethostby*(), each time registering the hostent in some list along with the > > thread's PID. If the same thread calls gethostby*, use the same buffer, or > > allocate a new one if another thread calls it. Have a static function be called > > atexit to free all the mallocs. > > Yuk! > > If you're writing a multithreaded program, a slightly different API for > gethostbyname() is likely to be the least of your worries. Agreed. gethostbyname_r() on solaris requires the caller to provide the address to write into, which is IMO the correct solution. Yes, it's a different API. But, the other alternatives are worse. The user must be able to control his memory allocation. For example, in a typical networking application, gethostbyname() could be called thousands or millions of times, and allocating memory everytime that can't be cleaned up until the program exits is completely unacceptable. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---Louis A. Mamakos said: >> ---Steve Tarkalson said: >> > this is solved by one of two methods: >> >1-) require the caller of gethostbyaddr() to supply a pointer to >> >a hostent struct which will be filled. >> > or 2-) the library uses thread specific storage which is re-used in >> >each call. >> > >> You could malloc() a struct hostent for each call to >> gethostby*(), each time registering the hostent in some list along with the >> thread's PID. If the same thread calls gethostby*, use the same buffer, or >> allocate a new one if another thread calls it. Have a static function be > called >> atexit to free all the mallocs. > > Yuk! > > If you're writing a multithreaded program, a slightly different API for > gethostbyname() is likely to be the least of your worries. > 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
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. Thanks, Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
---Dan Moschuk said: > > | 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. That's what I meant by an API change. Sorry for not being clearer. However, if you can roll in reentrancy without having to add the _r functions, that would save some sweat on the programmers' side. >>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. > Go for it! Someone needs to. :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
New kernel drivers
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? Thanks! -Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Configuration mechanism of PCI bus
Even with "PCI System Architecture, 4th edition" at hand, I still have some problems understanding the code in isa/pcibus.c. Please point out any misunderstanding I may have in the following: (1) At first, you can not modify the address port at 0xcf8 without a FULL 32-bit write. The routine pci_cfgopen() seems to use this fact. (2) The constant CONF1_ENABLE_MSK includes 4 higher bus number bits, only 4 bits can be used as bus number, so we can have at most 16 PCI buses. (3) The variable "mode1res" seems to refer to any residual left by BIOS in the address port. If it is non-zero, we will try to find a device using configuration mechanism 1. (3) The magic constant 0xf870ff excludes many devices. How it is chosen? I guess those excluded devices are not important or supported by FreeBSD. It seems to me that if pci_cfgcheck() finds at least one device, then the configuration mechanism is regarded as correctly detected. Any help is appreciated. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd-hackers-digest V4 #576
> > I believe the joystick driver in FreeBSD could probably be redone, to support > all the non-standard joysticks that many people (like me :) have. Having > just recently converted to FreeBSD from Linux, though, I don't know the best > way to go about it. Here are some ideas (sorry if my terminology is wrong): > > (1) Redefine the core joystick code as a controller, and then have all the > different joystick types ride on top of it, like: > > controller joy0at isa? port IO_GAME # Serves joystick port 0x201 > #device jan0at joy0 # Analog joystick > device jgpp0 at joy0 # Gravis GamePad Pro > etc... > This would also allow for modules to be used for all the different joystick > types, I think. > > (2) Have a monolithic joystick driver, with options to pick the proper type: > > device joy0at isa? port IO_GAME # Just like it is now > options JOY_ANALOG > options JOY_GRAVIS > etc... > > I also believe it should use the Linux joystick's device interface, so that > folks that have already written their games to use the Linux joysticks can work > in FreeBSD with minor effort. > > Any help or comments are appreciated. > I'm partway through porting Vojtech's Linux joystick code to FreeBSD, as a series of loadable modules. There is the main module (which is mostly converted, although some of the Linuxisms are a bit hard to come up with an equivalent to, even with the Linux device drivers book) and a seperate module for each of the different hardware devices. You'll kldload the main module first, then the device specific module, which'll call a joystick registration routine to make itself known. You've just spurred me into action and I hope to get the main module finished this weekend. The recent chatter about allowing kldload to give modules arguments is very interesting, as it would allow one to specify port addresses and the like. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd-hackers-digest V4 #576
On Tue, 10 Aug 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > > > > > I believe the joystick driver in FreeBSD could probably be redone, to support > > all the non-standard joysticks that many people (like me :) have. Having > > just recently converted to FreeBSD from Linux, though, I don't know the best > > way to go about it. Here are some ideas (sorry if my terminology is wrong): > > > > (1) Redefine the core joystick code as a controller, and then have all the > > different joystick types ride on top of it, like: > > > > controller joy0at isa? port IO_GAME # Serves joystick port 0x201 > > #device jan0at joy0 # Analog joystick > > device jgpp0 at joy0 # Gravis GamePad Pro > > etc... > > This would also allow for modules to be used for all the different joystick > > types, I think. > > > > (2) Have a monolithic joystick driver, with options to pick the proper type: > > > > device joy0at isa? port IO_GAME # Just like it is now > > options JOY_ANALOG > > options JOY_GRAVIS > > etc... > > > > I also believe it should use the Linux joystick's device interface, so that > > folks that have already written their games to use the Linux joysticks can work > > in FreeBSD with minor effort. > > > > Any help or comments are appreciated. > > > > I'm partway through porting Vojtech's Linux joystick code to FreeBSD, as a > series of loadable modules. There is the main module (which is mostly > converted, although some of the Linuxisms are a bit hard to come up with an > equivalent to, even with the Linux device drivers book) and a seperate module > for each of the different hardware devices. You'll kldload the main module > first, then the device specific module, which'll call a joystick registration > routine to make itself known. You've just spurred me into action and I hope to > get the main module finished this weekend. > > The recent chatter about allowing kldload to give modules arguments is very > interesting, as it would allow one to specify port addresses and the like. > > Stephen Well, I was going to try to roll my own for this, but it's always nice to know someone's already done it for me. :) I'm gone though for the next couple weeks though, so that'll be a nice thing to get back home to. Many thanks! Where will I be able to get it? -Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd-hackers-digest V4 #576
Stephen Hocking wrote: > The recent chatter about allowing kldload to give modules arguments is very > interesting, as it would allow one to specify port addresses and the like. Would it be useful to be able to be able to do something like this: kldload -t kernel_config /sys/i386/conf/YOURKERNELNAME ... and have drivers consult the information they find in there for config hints? If newbus knew how to reconstruct config_devtab at runtime by parsing a "kernel_config" module's "device" and "controller" lines, we'd get dynamic runtime reconfiguration for free. It could even defer the initial construction of config_devtab until boot-time if you used "options INCLUDE_CONFIG_FILE" to provide default configuration data... - mark Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd-hackers-digest V4 #576
> > Stephen > Well, I was going to try to roll my own for this, but it's always nice to > know someone's already done it for me. :) I'm gone though for the next > couple weeks though, so that'll be a nice thing to get back home to. Many > thanks! > > Where will I be able to get it? > > -Joe > Well, it's not ready yet. I'll be putting it in as a PR once I've finished. Probably it'll be released to the multimedia group first as a test. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
Joe Groff wrote: > > ---Louis A. Mamakos said: > >> You could malloc() a struct hostent for each call to > >> gethostby*(), each time registering the hostent in some list along with the > >> thread's PID. If the same thread calls gethostby*, use the same buffer, or > >> allocate a new one if another thread calls it. Have a static function be > > called > >> atexit to free all the mallocs. > > > > Yuk! > > > > If you're writing a multithreaded program, a slightly different API for > > gethostbyname() is likely to be the least of your worries. > > > 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. -- "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.
Joe Groff wrote: > > ---Dan Moschuk said: > > > > | 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. > That's what I meant by an API change. Sorry for not being clearer. > However, if you can roll in reentrancy without having to add the _r > functions, that would save some sweat on the programmers' side. No, it wouldn't, because any existing programs that already handle name server queries within threads will already use the gethostby*_r APIs. > >>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. > > > Go for it! Someone needs to. :) Here are the prototypes. Hosts: #include #include #include #include #include struct hostent *gethostbyname_r(const char *name, struct hostent *result, char *buffer, int buflen, int *h_errnop); struct hostent *gethostbyaddr_r(const char *addr, int length, int type, struct hostent *result, char *buffer, int buflen, int *h_errnop); struct hostent *gethostent_r(struct hostent *result, char *buffer, int buflen, int *h_errnop); Nets: #include struct netent *getnetbyname_r(const char *name, struct netent *result, char *buffer, int buflen); struct netent *getnetbyaddr_r(long net, int type, struct netent *result, char *buffer, int buflen); struct netent *getnetent_r(struct netent *result, char *buffer, int buflen); Protocols: #include struct protoent *getprotobyname_r(const char *name, struct protoent *result, char *buffer, int buflen); struct protoent *getprotobynumber_r(int proto, struct protoent *result, char *buffer, int buflen); struct protoent *getprotoent_r(struct protoent *result, char *buffer, int buflen); Services: #include struct servent *getservbyname_r(const char *name, const char *proto, struct servent *result, char *buffer, int buflen); struct servent *getservbyport_r(int port, const char *proto, struct servent *result, char *buffer, int buflen); struct servent *getservent_r(struct servent *result, char *buffer, int buflen); RPC services: #include struct rpcent *getrpcbyname_r(const char * name, struct rpcent *result, char *buffer, int buflen); struct rpcent *getrpcbynumber_r(const int number, struct rpcent *result, char *buffer, int buflen); struct rpcent *getrpcent_r(struct rpcent *result, char *buffer, int buflen); Any questions? -- "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 Mon, 9 Aug 1999, Wes Peters wrote: > Here are the prototypes. Hosts: > > #include > #include > #include > #include > #include > > struct hostent *gethostbyname_r(const char *name, > struct hostent *result, char *buffer, int buflen, > int *h_errnop); > > struct hostent *gethostbyaddr_r(const char *addr, > int length, int type, struct hostent *result, > char *buffer, int buflen, int *h_errnop); > > struct hostent *gethostent_r(struct hostent *result, > char *buffer, int buflen, int *h_errnop); > > Nets: > > #include > > struct netent *getnetbyname_r(const char *name, > struct netent *result, char *buffer, int buflen); > > struct netent *getnetbyaddr_r(long net, int type, > struct netent *result, char *buffer, int buflen); > > struct netent *getnetent_r(struct netent *result, > char *buffer, int buflen); > > Protocols: > > #include > > struct protoent *getprotobyname_r(const char *name, > struct protoent *result, char *buffer, int buflen); > > struct protoent *getprotobynumber_r(int proto, > struct protoent *result, char *buffer, int buflen); > > struct protoent *getprotoent_r(struct protoent *result, > char *buffer, int buflen); > > Services: > > #include > > struct servent *getservbyname_r(const char *name, > const char *proto, struct servent *result, > char *buffer, int buflen); > > struct servent *getservbyport_r(int port, const char *proto, > struct servent *result, char *buffer, int buflen); > > struct servent *getservent_r(struct servent *result, > char *buffer, int buflen); > > RPC services: > > #include > > struct rpcent *getrpcbyname_r(const char * name, > struct rpcent *result, char *buffer, int buflen); > > struct rpcent *getrpcbynumber_r(const int number, > struct rpcent *result, char *buffer, int buflen); > > 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. -Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New kernel drivers
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. eT 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/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] 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 [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
