The use of /stand/sysinstall to do a live upgrade has always been
discouraged, though it's not outright disallowed since I believe in
every man's right to blow his feet off if he really wants to.
Nonetheless, for the expected installation experience one is
encouraged to boot the desired OS releas
hi, there!
are there any device drivers for any *BSD for DigiBoard AccelePort C/X or
should I start writing them myself?
/fjoe
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
On 11-Aug-99 Matthew Dillon wrote:
> If the interrupt scans or in any way accesses the buffer list,
> you have to disable interrupts temporarily using the appropriate
> spl*() calls whenever your non-interrupt code (i.e. the ioctl code)
> makes modifications to the list. Other
hi, there!
are there any device drivers for any *BSD for DigiBoard AccelePort C/X or
should I start writing them myself?
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:size - to be malloc'ed. The tail queue holding the newly-
:allocated buffers is a local copy, and not subject to change
:in the event of an interrupt meant for the driver. Given
If the interrupt scans or in any way accesses the buffer list,
you have to disable interrupts temporarily using
On 11-Aug-99 Matthew Dillon wrote:
> If the interrupt scans or in any way accesses the buffer list,
> you have to disable interrupts temporarily using the appropriate
> spl*() calls whenever your non-interrupt code (i.e. the ioctl code)
> makes modifications to the list. Othe
We are experiencing what appears to be a memory corruption
problem with a kernel device driver running under FreeBSD
2.2.8-STABLE with the CAM patches.
The driver manages a series of memory buffers implemented
using a singly-linked tail list. The number and size of
buffers may be changed via an io
:size - to be malloc'ed. The tail queue holding the newly-
:allocated buffers is a local copy, and not subject to change
:in the event of an interrupt meant for the driver. Given
If the interrupt scans or in any way accesses the buffer list,
you have to disable interrupts temporarily usin
We are experiencing what appears to be a memory corruption
problem with a kernel device driver running under FreeBSD
2.2.8-STABLE with the CAM patches.
The driver manages a series of memory buffers implemented
using a singly-linked tail list. The number and size of
buffers may be changed via an i
Hello All.
I have a question. I buy 6 MegaRAID Ultra PCI SCSI Disk Array Controller's
and want to use they in FreeBSD, but not found driver. I wrote to
supp...@ami.com and they siad that no driver for FreeBSD. I found driver for
Linux and want use it in FreeBSD 3.1-3.2. How ?
P.S. Sorry f
Hello All.
I have a question. I buy 6 MegaRAID Ultra PCI SCSI Disk Array Controller's
and want to use they in FreeBSD, but not found driver. I wrote to
[EMAIL PROTECTED] and they siad that no driver for FreeBSD. I found driver for
Linux and want use it in FreeBSD 3.1-3.2. How ?
P.S. Sorr
could you tell me, what size is ppp header on FreeBSD?
anton.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Hi folks,
I've just gotten feedback from PR 12777, in which at least 2 people are
complaining that sysinstall as installed by 3.1-RELEASE can not be used
to upgrade a live machine to 3.2-RELEASE on the fly.
I've told both parties that they need to use a boot floppy with the
correct version of sy
"Daniel C. Sobral" writes:
> Of foremost importance, though, check the license.
Are we still talking about irs? I don't find any particular strange
licenses in src/lib/irs in recent bind distributions:
/assar
/*
* Copyright (c) 1996,1999 by Internet Software Consortium.
*
* Permission to us
could you tell me, what size is ppp header on FreeBSD?
anton.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Hi folks,
I've just gotten feedback from PR 12777, in which at least 2 people are
complaining that sysinstall as installed by 3.1-RELEASE can not be used
to upgrade a live machine to 3.2-RELEASE on the fly.
I've told both parties that they need to use a boot floppy with the
correct version of s
"Daniel C. Sobral" <[EMAIL PROTECTED]> writes:
> Of foremost importance, though, check the license.
Are we still talking about irs? I don't find any particular strange
licenses in src/lib/irs in recent bind distributions:
/assar
/*
* Copyright (c) 1996,1999 by Internet Software Consortium.
*
In message <37b05320.e6722...@newsguy.com> "Daniel C. Sobral" writes:
: Well, Terry does, though I don't quite recall his reasoning. :-)
: Notice, he objects the way FreeBSD is today, with the bind resolver
: API inside libc.
The size of _res has changed. Although it starts with an _, it is
offic
On Tue, 10 Aug 1999, Chris Csanady wrote:
> I don't know, but I came across this at SGI:
>
> http://oss.sgi.com/projects/xfs/
>
> It looks as though they plan to release it under the GPL. :(
This is why people should start emailing asking for a dual-license that
would support incorporatio
Thank you for this link. I assume that SGI will release the XFS code
under some species of corporate community licensing scheme. The
BSD/XFS will be implemented as an optional bolt-on set of kernel
modules in a manner designed to avoid GPL-ifying the BSD kernel.
I currently believe that this can
On Tue, 10 Aug 1999, Chris Csanady wrote:
> I don't know, but I came across this at SGI:
>
> http://oss.sgi.com/projects/xfs/
>
> It looks as though they plan to release it under the GPL. :(
So? It can still be distributed with FreeBSD. How many people are
going to want to modify this c
"Alton, Matthew" wrote:
>
> I am currently conducting a thorough study of the VFS subsystem
> in preparation for an all-out effort to port SGI's XFS filesystem to
> FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon
> has written in hackers- that the VFS subsystem is presently not
> w
In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes:
: Well, Terry does, though I don't quite recall his reasoning. :-)
: Notice, he objects the way FreeBSD is today, with the bind resolver
: API inside libc.
The size of _res has changed. Although it starts with an _, it is
officially part
On Tue, 10 Aug 1999, Chris Csanady wrote:
> I don't know, but I came across this at SGI:
>
> http://oss.sgi.com/projects/xfs/
>
> It looks as though they plan to release it under the GPL. :(
This is why people should start emailing asking for a dual-license that
would support incorporati
Thank you for this link. I assume that SGI will release the XFS code
under some species of corporate community licensing scheme. The
BSD/XFS will be implemented as an optional bolt-on set of kernel
modules in a manner designed to avoid GPL-ifying the BSD kernel.
I currently believe that this can
On Tue, 10 Aug 1999, Chris Csanady wrote:
> I don't know, but I came across this at SGI:
>
> http://oss.sgi.com/projects/xfs/
>
> It looks as though they plan to release it under the GPL. :(
So? It can still be distributed with FreeBSD. How many people are
going to want to modify this
"Alton, Matthew" wrote:
>
> I am currently conducting a thorough study of the VFS subsystem
> in preparation for an all-out effort to port SGI's XFS filesystem to
> FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon
> has written in hackers- that the VFS subsystem is presently not
>
Dan Moschuk wrote:
>
> Does anyone have any issues with merging the new bind resolver API into
> libc?
Well, Terry does, though I don't quite recall his reasoning. :-)
Notice, he objects the way FreeBSD is today, with the bind resolver
API inside libc.
Of foremost importance, though, check the l
On Tue, 10 Aug 1999, Wes Peters wrote:
> Dan Moschuk wrote:
> >
> > | > Yeah, that IS a horrible idea of mine. :) Changing the API should be a
> > last
> > | > resort, though, since we don't want to introduce to many FreeBSDisms
> > into the
> > | > already-fragmented-enough Unix world.
> > |
Dan Moschuk wrote:
>
> | > Yeah, that IS a horrible idea of mine. :) Changing the API should be a
> last
> | > resort, though, since we don't want to introduce to many FreeBSDisms into
> the
> | > already-fragmented-enough Unix world.
> | >
> | > Just a thought, how does Linux's GNU libc handle
Dan Moschuk wrote:
>
> Does anyone have any issues with merging the new bind resolver API into
> libc?
Well, Terry does, though I don't quite recall his reasoning. :-)
Notice, he objects the way FreeBSD is today, with the bind resolver
API inside libc.
Of foremost importance, though, check the
On Tue, 10 Aug 1999, Wes Peters wrote:
> Dan Moschuk wrote:
> >
> > | > Yeah, that IS a horrible idea of mine. :) Changing the API should be a last
> > | > resort, though, since we don't want to introduce to many FreeBSDisms into the
> > | > already-fragmented-enough Unix world.
> > | >
> > |
| } If no one has any objections, I'd like to start on this tomorrow.
|
| You might want to grab the latest BIND release from ftp.isc.org. One
| of the comments in the CHANGES file from a while ago is:
|
| 384. [feature] there is now a nearly-thread-safe resolver API, with
|
| > 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?
|
|
Dan Moschuk wrote:
>
> | > Yeah, that IS a horrible idea of mine. :) Changing the API should be a last
> | > resort, though, since we don't want to introduce to many FreeBSDisms into the
> | > already-fragmented-enough Unix world.
> | >
> | > Just a thought, how does Linux's GNU libc handle getho
| } If no one has any objections, I'd like to start on this tomorrow.
|
| You might want to grab the latest BIND release from ftp.isc.org. One
| of the comments in the CHANGES file from a while ago is:
|
| 384. [feature] there is now a nearly-thread-safe resolver API, with
|
| > 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?
|
| P
>> 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 loo
On Aug 9, 9:21pm, Dan Moschuk wrote:
} Subject: Re: gethostbyaddr() and threads.
}
} | Well, I guess we might as well change the API, since everyone else does.
Unless
} | someone comes up with a bettter idea, of course :)
} |
} | -Joe
}
} The API should not change. There is already enough des
Dan Moschuk wrote:
>
>A quicker fix would be just to enclose those global variables in
>mutexes.
God, no. The resolver is already stupidly unparallelizable -- there's
no need to make it thread-resistant too.
Tony.
--
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix
To Unsubsc
>> 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 lo
On Aug 9, 9:21pm, Dan Moschuk wrote:
} Subject: Re: gethostbyaddr() and threads.
}
} | Well, I guess we might as well change the API, since everyone else does. Unless
} | someone comes up with a bettter idea, of course :)
} |
} | -Joe
}
} The API should not change. There is already enough des
Dan Moschuk <[EMAIL PROTECTED]> wrote:
>
>A quicker fix would be just to enclose those global variables in
>mutexes.
God, no. The resolver is already stupidly unparallelizable -- there's
no need to make it thread-resistant too.
Tony.
--
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e
John Birrell wrote:
> I have an application which should use VxWorks like the rest of the
> project, but since this part has been subcontracted, Wind River wants
> A$35,000 for an OEM licence for the right to link to
> their libraries. Blood suckers. They only charge A$5990 for the tools!
>
> I a
John Birrell wrote:
> I have an application which should use VxWorks like the rest of the
> project, but since this part has been subcontracted, Wind River wants
> A$35,000 for an OEM licence for the right to link to
> their libraries. Blood suckers. They only charge A$5990 for the tools!
>
> I
Hi,
I am looking at the STAILQ macros defined in and I am curious why
it is necessary to declare stqh_last in the STAILQ_HEAD as a pointer to
pointer, rather than just a pointer? (like the head pointer)
Please don't laugh too hard.. my head hurts :)
---
Daniel O'Connor software and network engin
Hi,
I am looking at the STAILQ macros defined in and I am curious why
it is necessary to declare stqh_last in the STAILQ_HEAD as a pointer to
pointer, rather than just a pointer? (like the head pointer)
Please don't laugh too hard.. my head hurts :)
---
Daniel O'Connor software and network engi
Is there anyone using FreeBSD on a VMEbus PC?
I have an application which should use VxWorks like the rest of the
project, but since this part has been subcontracted, Wind River wants
A$35,000 for an OEM licence for the right to link to
their libraries. Blood suckers. They only charge A$5990 for
Is there anyone using FreeBSD on a VMEbus PC?
I have an application which should use VxWorks like the rest of the
project, but since this part has been subcontracted, Wind River wants
A$35,000 for an OEM licence for the right to link to
their libraries. Blood suckers. They only charge A$5990 for
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
50 matches
Mail list logo
