On Wed, Jun 27, 2001 at 06:29:15PM -0700, Dima Dorfman wrote:
> Ruslan Ermilov <[EMAIL PROTECTED]> writes:
> > On Wed, Jun 27, 2001 at 01:29:28AM -0700, Dima Dorfman wrote:
> > > Ruslan Ermilov <[EMAIL PROTECTED]> writes:
> > > > On Tue, Jun 26, 2001 at 03:04:07PM -0700, Dima Dorfman wrote:
> > >
(on -hackers only, as this post is beyond the -smp charter)
> > Am I correct that libc_r does _not_ use multiple processes to create
> > threads? Grepping for "fork" in *.c files under /usr/src/lib/libc_r
> > leads me to believe that this is so...
>
>That's correct. It's implemented using
On Friday, June 29, 2001, E.B. Dreger wrote:
> Am I correct that libc_r does _not_ use multiple processes to create
> threads? Grepping for "fork" in *.c files under /usr/src/lib/libc_r leads
> me to believe that this is so...
That's correct. It's implemented using setjmp/longjmp, and
storin
Julian Elischer wrote:
> bridging is not a function of it being a pc-card..
This is true, particularly with netgraph bridging.
> actually bridging may already work with wi cards
> also netgraph bridgiung may also work...
>
Bridging cannot work with wi cards, since they do not support
prom
> Date: Thu, 28 Jun 2001 21:28:56 -0500
> From: Chris Costello <[EMAIL PROTECTED]>
>
> > Please pardon the cross-posting; I'd rather keep responses on whichever
> > list is more appropriate.
>
>Currently, the pthreads implementation is done entirely in
> userland. This means that a syscall
Hi,
Btw, did I say that I'm planning to sell the 7951 based crypto board for
around $80 in single unnit volume, both for the PCI and MiniPCI
version
And Mike, if my answer is just a sentence, I like to keep it on top, so
people don't have to scroll all the way down to see what I'm writing...
> In a message dated 06/27/2001 11:06:12 PM Eastern Daylight Time,
> [EMAIL PROTECTED] writes:
>
> > That's not really the point here, I was talking about lowest end
> > hardware compared to high end CPU. If we compare with high end hardware,
> > then we're talking about factor >50 faster than
On Friday, June 29, 2001, E.B. Dreger wrote:
> Please pardon the cross-posting; I'd rather keep responses on whichever
> list is more appropriate.
>
> Why are bind(2), accept(2), kevent(2), etc. wrapped in libc_r?
Currently, the pthreads implementation is done entirely in
userland. This mean
The same question was asked by Ralf Knapp <[EMAIL PROTECTED]> - in fact,
the text of the question appears to be identical to the text of your
question - who sent his question to [EMAIL PROTECTED] and
[EMAIL PROTECTED]
The answer to that question was:
Date: Thu, 28 Jun 2001 11:34:10 -0500
Please pardon the cross-posting; I'd rather keep responses on whichever
list is more appropriate.
Why are bind(2), accept(2), kevent(2), etc. wrapped in libc_r?
I thought that the spl() calls prevented kernel recursion in the current
SMP system, and that a mutex handled reentrance in SMPng. [Pl
Dag-Erling Smorgrav wrote:
>
> Wes Peters <[EMAIL PROTECTED]> writes:
> > The description there isn't very forthcoming. fastforwarding caches
> > the results of a route lookup for destination addresses that are not
> > on the local machine, and uses the cached route to short-circuit the
> > norm
> > I am looking to find a simple way to control a serial port through BSD
> > (such as raising and lowering DTR for a specified duration). I thought I
> > had it using ioctl() and wrote a simple program to test it, but it seems I
> > don't have a full understanding of ioctl(). Does anyone know o
Could some body let me know, how to hack the FReeBSD kernel to learn the
exact sequence of steps which happen when the device driver interrupts the
FreeBSD Kernel for resources. Is there a trace debugger available, with
which i can find out the steps.
thanx
Vinu
> > I am looking to find a simple way to control a serial port through BSD
> > (such as raising and lowering DTR for a specified duration). I thought I
> > had it using ioctl() and wrote a simple program to test it, but it seems I
> > don't have a full understanding of ioctl(). Does anyone know o
On Thursday, June 14, 2001, Alexey Zelkin wrote:
> ps: But I think it can be good idea to put sgml'ified copy of this report (and
> others) to web site, like we had Really Quick Newsletter for some time. Any
> takers ?
Hmmm. I just noticed this email.
It sounds like a nice idea to keep it
Wes Peters <[EMAIL PROTECTED]> writes:
> The description there isn't very forthcoming. fastforwarding caches
> the results of a route lookup for destination addresses that are not
> on the local machine, and uses the cached route to short-circuit the
> normal (relatively slow) route lookup proces
On Thu, Jun 28, 2001 at 04:05:24PM -0400, Jason Borkowsky wrote:
>
> I am looking to find a simple way to control a serial port through BSD
> (such as raising and lowering DTR for a specified duration). I thought I
> had it using ioctl() and wrote a simple program to test it, but it seems I
> don
I am looking to find a simple way to control a serial port through BSD
(such as raising and lowering DTR for a specified duration). I thought I
had it using ioctl() and wrote a simple program to test it, but it seems I
don't have a full understanding of ioctl(). Does anyone know of any
pre-writte
On Thu, 28 Jun 2001, Nicolas Souchu wrote:
> Hi folks,
>
> I have a char driver that must be opened by more than one process. The minor
> index is not sufficient for this. Is there any process private data (void *)
> in the devfs structure (or the opposite) I could point to with the minor index
>
Thanks! I'll try it as soon as possible (I don't have a -stable machine ready, and I'd
rather not try my first "make world"
attempts on my production machine...)
Louis-Philippe Gagnon
- Original Message -
From: "Daniel Eischen" <[EMAIL PROTECTED]>
To: "Louis-Philippe Gagnon" <[EMAIL PRO
In a message dated 06/28/2001 12:23:24 AM Eastern Daylight Time,
[EMAIL PROTECTED] writes:
> > Personally I don't care much about BSD vs. GPL and am
> > annoyed by Microsoft's hypocricy (sp?). The fact that
> > they're using open source software is great.
>
> That was the point I was trying
In a message dated 06/27/2001 11:06:12 PM Eastern Daylight Time,
[EMAIL PROTECTED] writes:
> That's not really the point here, I was talking about lowest end
> hardware compared to high end CPU. If we compare with high end hardware,
> then we're talking about factor >50 faster than software...
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] w
rites:
>Hello,
>
>is it possible to allocate and then maybe free memory in user space
>from kernel mode, if I have struct proc of the process that memory should
>belong to ?
Yes.
>What is the easiest and safest method of doing this ?
Probably
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>Hi folks,
>
>I have a char driver that must be opened by more than one process. The minor
>index is not sufficient for this. Is there any process private data (void *)
>in the devfs structure (or the opposite) I could point to with the min
Hi folks,
I have a char driver that must be opened by more than one process. The minor
index is not sufficient for this. Is there any process private data (void *)
in the devfs structure (or the opposite) I could point to with the minor index
of my device?
Nicholas
--
Alcôve Technical Manager
Hello,
is it possible to allocate and then maybe free memory in user space
from kernel mode, if I have struct proc of the process that memory should
belong to ? What is the easiest and safest method of doing this ?
I have seen some example that uses obreak(), but that seems very tricky
and suspic
anyone seen this yet or am I slow as usual?
http://www.oreillynet.com/pub/a/dotnet/2001/06/27/dotnet.html
Ak
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Zhihui Zhang wrote:
> sbrk() is not supported in FreeBSD as a system call (see file
> vm/vm_mmap.c).
pancake:/sys> grep -w sbrk /usr/src/sys/kern/syscalls.master
69 STD BSD { int sbrk(int incr); }
If you use malloc() in your program, you shouldn't use sbrk, because doing
so will mak
I am sorry. It turns out when the argument is zero, sbrk() does not enter
into the kernel. If it does, it will return not supported.
-Zhihui
On Thu, 28 Jun 2001, Zhihui Zhang wrote:
>
> sbrk() is not supported in FreeBSD as a system call (see file
> vm/vm_mmap.c). However, sbrk(0) can reflec
sbrk() is not supported in FreeBSD as a system call (see file
vm/vm_mmap.c). However, sbrk(0) can reflect the latest end of the heap. I
am interested in how sbrk() interacts with malloc(). I know my question is
too specific. Thanks for your answer. I did learn a lesson: mixing
abstraction layers
I ´m using NeTraMet Vers. 4.3 on an FreeBSD 4.2 System (i386)
with libpcap-04.
NeTraMet uses libpcap for monitoring and get the packets on the LAN.
It could be that ethernet packets were dropped by the kernel and
NeTraMet, which happens when i capture some minutes of the LAN traffic
with tcpdu
Zhihui Zhang wrote:
>
> Suppose I write a program that calls sbrk(). How can I trace into the
> function sbrk()? In this particular case, I want to know whether
> sbrk() calls the function in file lib/libstand/sbrk.c or sys/sbrk.S.
> Sometimes it is nice to see what system call is eventually call
It is also possible that it would only write as much as it can,
and return the amount written, leaving it to you to write the rest
later. (Uhm.. you do check the return values from write(2), right? :)
The relevant source is in src/sys/kern/sys_pipe.c, namely the pipe_write()
function. From a qu
daniel lawrence wrote:
> This is probably a long shot, but I'll ask anyway. We have 3 HP9000/L1000
> machines which we may be able to make available (serial console and network)
> for some kind of BSD porting project.
I'm very interested in having a FreeBSD running on the newer HP9000 server
mac
34 matches
Mail list logo
