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
> ne
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. Shou
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 sur
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,
> i
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
> > UNI
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 anoth
> > 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
>
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. Sho
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/Y
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 L
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 sur
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,
>
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
>
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 anot
> > 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
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/
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
>
> 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 termin
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
>
> 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 termi
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
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 pc
---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,
| 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 sh
---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
>> >
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
---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,
| 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 sh
---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
>> >
> > ---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.
>
---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 sta
> ---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 cou
> > ---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.
>
---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 st
---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 st
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...@
> ---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 co
---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 s
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 PRO
---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
[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
wi
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/importqu
---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 b
[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
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/importq
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 th
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 sam
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
: 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 ar
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 proc
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 requi
: 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 a
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
| >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/n
| >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/
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/l
"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
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
"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 )
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 s
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 s
- 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 fol
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
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
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, whic
- 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 Int
: 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
67 matches
Mail list logo
