Re: HP9000/L1000
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 machines but i think the problem is getting the hardware documentation from HP (tell me if i'm wrong) for the Series 800 machines. Hardware is available here, if anyone is working on such a project and likes a helping hand, please mail. hellmuth -- Hellmuth Michaelis[EMAIL PROTECTED] Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: does data overflow in pipes
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 quick look, it would seem that writes behave exactly the way I thought - only writing as much as there is space left in the pipe buffer. G'luck, Peter -- I am the meaning of this sentence. On Wed, Jun 27, 2001 at 10:45:21PM -0400, Zhihui Zhang wrote: I guess the kernel will block the process trying to write more data than that can be accommodated. Or if you are using non-blocking I/O, it will return an error. -Zhihui On Wed, 27 Jun 2001, Manas Bhatt wrote: hi all, pipes uses only direct blocks to store data. so depending on the blocksize , a total data of 10*blocksize can be written in one go but what happens if a writer process tries to write more 10*blocksize of data in one go. Does the kernel overwrites the data in pipe or not ? if yes, why? if not, then how does it allow the writer to write more 10*blocksize of data? if someone can direct me to implementation (source files), it would be great. thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: trace a library call
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 called as well. I know dynamic linking may make this hard. But is there a way to do this? Thanks. sbrk() is a system call, not a library call. It has a stub that just loads a register with the call ID and does an INT 0x80. You can't trace into it, since you are in a user space program. If you want to see how it works, the sources are in /sys; but all it does is add pages to the end of the address space, in the heap. If you are having problems with it, you are probably using sbrk() and malloc() in the same program. Don't do that; malloc() traditionally calls sbrk() to get pages, so you will have the same effect as trying to use fopen() and open() in the same program: mainly, that fd manipulation routines can close/open/etc. fd's out from under file pointers. In the sbrk() case, there can be attempts to (re)map pages to regions where they don't really belong. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
how to compile bpf...
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 tcpdump 3.5 . Tcpdump gives an information about how many packets were filtered and how many packet were dropped by the kernel. NeTraMet doesn´t do this. How could i be on the secure site, that NeTraMet get all packets. If NeTraMet droppes the packets like tcpdump what can I do. In the newsforum from NeTraMet someone says to boost the bpf buffer but he didn´t know how. (the counter it is referring to in /sys/net/bpf.c in the kernel.) seems to be # define BPF_BUFSIZE 4096 so i have to increase this. And there for I have to recompile the c-source code, but which of the source and how. Where I have to put the binary?? Could you help me or give some hints?? Thanks in advance René Heimes To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: trace a library call
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 is really bad. -Zhihui On Thu, 28 Jun 2001, Terry Lambert wrote: 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 called as well. I know dynamic linking may make this hard. But is there a way to do this? Thanks. sbrk() is a system call, not a library call. It has a stub that just loads a register with the call ID and does an INT 0x80. You can't trace into it, since you are in a user space program. If you want to see how it works, the sources are in /sys; but all it does is add pages to the end of the address space, in the heap. If you are having problems with it, you are probably using sbrk() and malloc() in the same program. Don't do that; malloc() traditionally calls sbrk() to get pages, so you will have the same effect as trying to use fopen() and open() in the same program: mainly, that fd manipulation routines can close/open/etc. fd's out from under file pointers. In the sbrk() case, there can be attempts to (re)map pages to regions where they don't really belong. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: trace a library call
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 make the malloc() code lose count of what memory has been added to
the heap. The result of this is that your program will almost certainly
crash due to different memory objects being stored in the same area of
memory.
The version of sbrk in libstand is an emulation of the system call which is
not used for any programs running in multiuser mode (or at least, it
shouln't be, if it is).
Nick
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
allocating user space memory from kernel mode
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 suspicious ... I don't really understand what obreak() really does and how to use it ... Thanks for the information. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
processes private data
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 - [EMAIL PROTECTED] - http://www.alcove.com Open Source Software Developer - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: processes private data
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 minor index of my device? No. You want to split your minor number into separate unit and instance parts, and allow each instance to be only opened once (return EBUSY). A quick fix is to continue selecting the softc structure exclusively based on unit number and to hang the necessary per instance data off that. -- a href=http://www.poohsticks.org/drew/;Home Page/a For those who do, no explanation is necessary. For those who don't, no explanation is possible. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: allocating user space memory from kernel mode
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 vm_mmap with the MAP_ANON flag and without MAP_FIXED. I have seen some example that uses obreak(), but that seems very tricky and suspicious ... I don't really understand what obreak() really does and how to use it ... I wouldn't want to confuse the user land memory allocators by changing heap size. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
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 There are chips out that can do 1Gbit 3-DES, given a 64bit/66Mhz PCI bus. I'm just starting with a low end chip to complement my 133 Mhz 486 based net4501 board, with the goal of low cost and low power, not absolute performance. Its cheaper and more flexible to buy a faster motherboard, which is the point to the rest of us who are deciding if we care about a hardware solution. Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Query: How to tell if Microsoft is using BSD TCP/IP code?
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 to make. Rather than be annoyed by this, it should be splashed across /., lwn, etc. But I'm not gonna do it. Maybe ESR will if you tell him. I dont think that microsoft is being hypocritical. They dont generally say that open source has no value, only that they dont agree that its a viable strategy for marketing commercial products. I dont think that the fact that they use some code as a base for their products contradicts that position at all. Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pthread/longjmp/signal problem
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 PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, June 26, 2001 5:08 PM
Subject: Re: pthread/longjmp/signal problem
On Thu, 21 Jun 2001, Louis-Philippe Gagnon wrote:
No reactions the first time, let's try again.
I've encountered a problem in the interaction betwen signals, longjmp and
pthreads; I'm hoping someone can help me make sense of it.
I've been trying to implement a IsBadReadPtr-style function in FreeBSD by
using signal handlers and longjmp/setjmp. It seemed to work as expected,
until I started using the -pthread option to gcc (thus linking against
libc_r). Now the function only works on the first call; subsequent calls
hang on the segmentation fault.
Here's an example of the kind of code that causes problems :
Try this patch (to -stable). Only the patch to uthread_sig.c is
needed for -current.
--
Dan Eischen
Index: libc/i386/gen/setjmp.S
===
RCS file: /opt/FreeBSD/cvs/src/lib/libc/i386/gen/setjmp.S,v
retrieving revision 1.17.2.1
diff -u -r1.17.2.1 setjmp.S
--- libc/i386/gen/setjmp.S 2000/05/16 20:43:21 1.17.2.1
+++ libc/i386/gen/setjmp.S 2001/06/26 21:07:23
@@ -61,11 +61,7 @@
pushl %eax /* (sigset_t*)oset */
pushl $0 /* (sigset_t*)set */
pushl $1 /* SIG_BLOCK */
-#ifdef _THREAD_SAFE
- call PIC_PLT(CNAME(_thread_sys_sigprocmask))
-#else
call PIC_PLT(CNAME(sigprocmask))
-#endif
addl $12,%esp
PIC_EPILOGUE
movl 4(%esp),%ecx
@@ -91,11 +87,7 @@
leal 28(%edx), %eax
pushl %eax /* (sigset_t*)set */
pushl $3 /* SIG_SETMASK */
-#ifdef _THREAD_SAFE
- call PIC_PLT(CNAME(_thread_sys_sigprocmask))
-#else
call PIC_PLT(CNAME(sigprocmask))
-#endif
addl $12,%esp
PIC_EPILOGUE
movl 4(%esp),%edx
Index: libc/i386/gen/sigsetjmp.S
===
RCS file: /opt/FreeBSD/cvs/src/lib/libc/i386/gen/sigsetjmp.S,v
retrieving revision 1.19.2.1
diff -u -r1.19.2.1 sigsetjmp.S
--- libc/i386/gen/sigsetjmp.S 2000/05/16 20:43:21 1.19.2.1
+++ libc/i386/gen/sigsetjmp.S 2001/06/26 21:04:34
@@ -70,11 +70,7 @@
pushl %eax /* (sigset_t*)oset */
pushl $0 /* (sigset_t*)set */
pushl $1 /* SIG_BLOCK */
-#ifdef _THREAD_SAFE
- call PIC_PLT(CNAME(_thread_sys_sigprocmask))
-#else
call PIC_PLT(CNAME(sigprocmask))
-#endif
addl $12,%esp
PIC_EPILOGUE
movl 4(%esp),%ecx
@@ -102,11 +98,7 @@
leal 28(%edx), %eax
pushl %eax /* (sigset_t*)set */
pushl $3 /* SIG_SETMASK */
-#ifdef _THREAD_SAFE
- call PIC_PLT(CNAME(_thread_sys_sigprocmask))
-#else
call PIC_PLT(CNAME(sigprocmask))
-#endif
addl $12,%esp
PIC_EPILOGUE
movl 4(%esp),%edx
Index: libc_r/uthread/uthread_sig.c
===
RCS file: /opt/FreeBSD/cvs/src/lib/libc_r/uthread/uthread_sig.c,v
retrieving revision 1.25.2.7
diff -u -r1.25.2.7 uthread_sig.c
--- libc_r/uthread/uthread_sig.c 2001/06/23 00:47:05 1.25.2.7
+++ libc_r/uthread/uthread_sig.c 2001/06/26 20:56:52
@@ -931,6 +931,12 @@
thread-curframe = NULL;
PTHREAD_ASSERT(psf != NULL, Invalid signal frame in signal handler);
+ /*
+ * We came here from the kernel scheduler; clear the in scheduler
+ * flag.
+ */
+ _thread_kern_in_sched = 0;
+
/* Check the threads previous state: */
if (psf-saved_state.psd_state != PS_RUNNING) {
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Serial port control
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-written utilities I can use? Or where to get some really detailed information about ioctl()? Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Serial port control
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't have a full understanding of ioctl(). Does anyone know of any pre-written utilities I can use? Or where to get some really detailed information about ioctl()? Thanks! Many links at: http://www.stokely.com/unix.serial.port.resources/ in particular: http://www.easysw.com/~mike/serial/serial.html -- Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org PGP signature
Re: FreeBSD Monthly Development Status Report, June 2001
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 in www, actually. Do you mean formatted using DocBook, or just HTML? -- +---++ | Chris Costello| All new: | | [EMAIL PROTECTED] | The software is not compatible with previous versions. | +---++ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Serial port control
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-written utilities I can use? Or where to get some really detailed
information about ioctl()? Thanks!
Many links at: http://www.stokely.com/unix.serial.port.resources/
in particular: http://www.easysw.com/~mike/serial/serial.html
I thought I maybe had this under control, but not yet.
I am trying to control the serial control lines on a FreeBSD 4.2 box, and
wrote a simple program (included below). This program polls the serial
controller for its current state, displays the state, and then attempts to
set the state of two of the control lines (lower RTS and DTR). However,
after telling ioctl() to lower RTS and DTR, and then polling the status
again, RTS and DTR are still high. Does anyone know which serial control
lines FreeBSD allows you to manipulate and why this isn't working?
To compile the program, merely save it as text, gcc the text file, and
run. Any insight is greatly appreciated!
#include stdio.h
#include fcntl.h
#include errno.h
#include termios.h
main () {
int fd; /* File descriptor for serial port */
int status; /* Serial port status bitmask */
fd = open(/dev/cuaa0, O_RDWR | O_NOCTTY | O_NDELAY);
if (fd == -1)
perror(open_port: Unable to open /dev/ttyf1 - );
else
fcntl(fd, F_SETFL, 0);
/* Get serial line status bits */
ioctl(fd,TIOCMGET,status);
/*Signal Values, obtained from ttycom.h
*
*1 - DSR (Data Set Ready)
*2 - DTR (Data Terminal Ready)
*4 - RTS (Request to Send)
*8 - ST (Secondary Transmit)
*16 - SR (Secondary Receive)
*32 - CTS (Clear to Send)
*64 - DCD (Data Carrier Detect)
*128 - RNG (Ring)
*256 - DSR (Data Set Ready)
*/
printf (Current Serial Settings:);
if (status = TIOCM_DSR) {
status -= TIOCM_DSR;
printf ( DSR );
}
if (status = TIOCM_RNG) {
status -= TIOCM_RNG;
printf ( Ring );
}
if (status = TIOCM_CD) {
status -= TIOCM_CD;
printf ( DCD );
}
if (status = TIOCM_CTS) {
status -= TIOCM_CTS;
printf ( CTS );
}
if (status = TIOCM_SR) {
status -= TIOCM_SR;
printf ( SR );
}
if (status = TIOCM_ST) {
status -= TIOCM_ST;
printf ( ST );
}
if (status = TIOCM_RTS) {
status -= TIOCM_RTS;
printf ( RTS );
}
if (status = TIOCM_DTR) {
status -= TIOCM_DTR;
printf ( DTR );
}
if (status = TIOCM_LE) {
status -= TIOCM_LE;
printf ( DSR );
}
printf(\n);
/* SET STATUS to 1 (DTR and RTS lowered). Previous status was 7 (DSR, DTR,
* RTS high).
*/
status = 1;
ioctl(fd,TIOCMSET,status);
/* Check status after setting serial control bits */
ioctl(fd,TIOCMGET,status);
printf (Current Serial Settings:);
if (status = TIOCM_DSR) {
status -= TIOCM_DSR;
printf ( DSR );
}
if (status = TIOCM_RNG) {
status -= TIOCM_RNG;
printf ( Ring );
}
if (status = TIOCM_CD) {
status -= TIOCM_CD;
printf ( DCD );
}
if (status = TIOCM_CTS) {
status -= TIOCM_CTS;
printf ( CTS );
}
if (status = TIOCM_SR) {
status -= TIOCM_SR;
printf ( SR );
}
if (status = TIOCM_ST) {
status -= TIOCM_ST;
printf ( ST );
}
if (status = TIOCM_RTS) {
status -= TIOCM_RTS;
printf ( RTS );
}
if (status = TIOCM_DTR) {
status -= TIOCM_DTR;
printf ( DTR );
}
if (status = TIOCM_LE) {
status -= TIOCM_LE;
printf ( DSR );
}
printf(\n);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
interrupt on to Kernel
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 _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Serial port control
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-written utilities I can use? Or where to get some really detailed
information about ioctl()? Thanks!
After several responses, I thought I had it. From a software point of
view, my program, included below, works fine. But from a hardware point of
view, the signals I am trying to lower, RTS and DTR, are staying
high. Can anyone try to compile the below program and do a serial port
test with an RS-232 tester and see if anyone actually sees RTS and DTR
going low? Sorry for bothering everyone with this again, but this is
driving me nuts and I can't figure out the problem now. Thanks!
#include stdio.h
#include fcntl.h
#include errno.h
#include termios.h
main () {
int fd; /* File descriptor for serial port */
int status; /* Serial port status bitmask */
int error = 0;
fd = open(/dev/cuaa0, O_RDWR | O_NOCTTY | O_NDELAY);
if (fd == -1)
perror(open_port: Unable to open /dev/ttyf1 - );
else
error = fcntl(fd, F_SETFL, 0);
if (error == -1)
perror(fcntl error - );
/* Get serial line status bitmask */
error = 0;
error = ioctl(fd,TIOCMGET,status);
if (error == -1)
perror(ioctl1 GET error - );
/*Signal Values
*
*1 - DSR (Data Set Ready)
*2 - DTR (Data Terminal Ready)
*4 - RTS (Request to Send)
*8 - ST (Secondary Transmit)
*16 - SR (Secondary Receive)
*32 - CTS (Clear to Send)
*64 - DCD (Data Carrier Detect)
*128 - RNG (Ring)
*256 - DSR (Data Set Ready)
*/
printf (Current Serial Settings:);
if (status = TIOCM_DSR) {
status -= TIOCM_DSR;
printf ( DSR );
}
if (status = TIOCM_RNG) {
status -= TIOCM_RNG;
printf ( Ring );
}
if (status = TIOCM_CD) {
status -= TIOCM_CD;
printf ( DCD );
}
if (status = TIOCM_CTS) {
status -= TIOCM_CTS;
printf ( CTS );
}
if (status = TIOCM_SR) {
status -= TIOCM_SR;
printf ( SR );
}
if (status = TIOCM_ST) {
status -= TIOCM_ST;
printf ( ST );
}
if (status = TIOCM_RTS) {
status -= TIOCM_RTS;
printf ( RTS );
}
if (status = TIOCM_DTR) {
status -= TIOCM_DTR;
printf ( DTR );
}
if (status = TIOCM_LE) {
status -= TIOCM_LE;
printf ( DSR );
}
printf(\n);
/* Lower DTR and RTS */
status = 1;
error = 0;
error = ioctl(fd,TIOCMSET,status);
if (error == -1)
perror (ioctl SET error - );
/* Hold the signals low, as they seem to reset when releasing the
* file descriptor
*/
sleep(10);
error = 0;
error = ioctl(fd,TIOCMGET,status);
if (error == -1)
perror (ioctl GET error - );
printf (Current Serial Settings:);
if (status = TIOCM_DSR) {
status -= TIOCM_DSR;
printf ( DSR );
}
if (status = TIOCM_RNG) {
status -= TIOCM_RNG;
printf ( Ring );
}
if (status = TIOCM_CD) {
status -= TIOCM_CD;
printf ( DCD );
}
if (status = TIOCM_CTS) {
status -= TIOCM_CTS;
printf ( CTS );
}
if (status = TIOCM_SR) {
status -= TIOCM_SR;
printf ( SR );
}
if (status = TIOCM_ST) {
status -= TIOCM_ST;
printf ( ST );
}
if (status = TIOCM_RTS) {
status -= TIOCM_RTS;
printf ( RTS );
}
if (status = TIOCM_DTR) {
status -= TIOCM_DTR;
printf ( DTR );
}
if (status = TIOCM_LE) {
status -= TIOCM_LE;
printf ( DSR );
}
printf(\n);
close(fd);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
libc_r locking... why?
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. [Please correct me if/where I am mistaken.] I can understand things like malloc(3), lseek(2), read(2), and write(2) being serialized, but I'm confused about [some of the other] syscall wrappers. Can somebody please elaborate, or direct me to a reference? Big TIA, Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: how to compile bpf...
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 From: Jon Dugan [EMAIL PROTECTED] To: Knapp, Ralf Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [tcpdump-workers] droped packets ?! how to increase the bpf buffer, or libpap buffer - You can set the BPF bufsize via sysctl: sysctl -w debug.bpf_bufsize=whatever See sysctl.conf(5) for more info about how to set this as part of the boot process. See sysctl(8) for more info on sysctl. and, given that your question was identical, the answer to your question is also identical - you don't have to recompile the kernel, just use sysctl. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
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 means that a syscall which would normally block needs to have code in it to check if it would block (write(2) is a really simple example of this), and if it would, schedule another thread (cancelling, or blocking, the calling thread) to run, and eventually get back to the thread which is blocking on write, check for/read more data, cancel again, etc., until the requested amount of data has been read or an error occurs. This example, of course, applies to instances where write() is called on a file descriptor which does _NOT_ have O_NONBLOCK set. kevent(2), bind(2), accept(2) etc. all do the same thing for the same reasons. -- +---+-+ | Chris Costello| Advanced design:| | [EMAIL PROTECTED] | Upper management doesn't understand it. | +---+-+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
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 There are chips out that can do 1Gbit 3-DES, given a 64bit/66Mhz PCI bus. I'm just starting with a low end chip to complement my 133 Mhz 486 based net4501 board, with the goal of low cost and low power, not absolute performance. Its cheaper and more flexible to buy a faster motherboard, which is the point to the rest of us who are deciding if we care about a hardware solution. Really? Have you even looked at the net4501 board which was mentioned? It's a single-board computer constructed for some specific communication applications, with no VGA or keyboard support, or spinning fans, and is pretty inexpensive and in a very small form factor. Why do I want to replace this with a new motherboard? Please consider that you probably can't imagine all the applications that these platforms might be used in, an the availability of fire-breathing Really Fast CPUs might not actually be applicable to some applications with very specific requirements. A new motherboard isn't going to be more flexible since it's likely to require a power supply larger than the whole low-power computer you propose to replace. I'd rather spend the $100 or $150 to add crypto performance for some applications and maintain the small form factor, low power consumption, and no moving parts. The rest of us covers quite a few people, with a variety of interesting applications. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
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 Soren Louis A. Mamakos wrote: 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 There are chips out that can do 1Gbit 3-DES, given a 64bit/66Mhz PCI bus. I'm just starting with a low end chip to complement my 133 Mhz 486 based net4501 board, with the goal of low cost and low power, not absolute performance. Its cheaper and more flexible to buy a faster motherboard, which is the point to the rest of us who are deciding if we care about a hardware solution. Really? Have you even looked at the net4501 board which was mentioned? It's a single-board computer constructed for some specific communication applications, with no VGA or keyboard support, or spinning fans, and is pretty inexpensive and in a very small form factor. Why do I want to replace this with a new motherboard? Please consider that you probably can't imagine all the applications that these platforms might be used in, an the availability of fire-breathing Really Fast CPUs might not actually be applicable to some applications with very specific requirements. A new motherboard isn't going to be more flexible since it's likely to require a power supply larger than the whole low-power computer you propose to replace. I'd rather spend the $100 or $150 to add crypto performance for some applications and maintain the small form factor, low power consumption, and no moving parts. The rest of us covers quite a few people, with a variety of interesting applications. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
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 which would normally block needs to have code in it to check if it would block (write(2) is a really simple example of this), and if it would, schedule another thread (cancelling, or blocking, the calling thread) to run, and eventually get back to the thread which is blocking on write, check for/read more data, cancel again, etc., until the requested amount of data has been read or an error occurs. So it's a thunk/kludge not only to enforce proper behavior, but also to prevent the process from blocking and stalling other threads? This makes sense. This example, of course, applies to instances where write() is called on a file descriptor which does _NOT_ have O_NONBLOCK set. kevent(2), bind(2), accept(2) etc. all do the same thing for the same reasons. The reason that I asked is because I'm writing a program that uses rfork() in the same manner as the new rfork_thread(). I couldn't understand the need to wrap kevent(2), bind(2), or accept(2)... In my mind, I was thinking data integrity, trying to prevent processes in the same thread family from stepping on one another. Blocking is not a problem; where I can't use non-blocking calls, I use a worker thread. I guess that I was looking at man pages and bits of libc_r code without understanding the pthread implementation. I knew that it was userland, but I thought that it created multiple processes... if this is not the case, then I was apparently comparing apples to mangoes. 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... ...I think that, with your prompting, I've answered my question. Thanks, Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bridging with pcmcia cards
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 promiscuous transmission (that is, sending frames with other than their own MAC address). Moreover, anyone seriously desiring to bridge wi cards very likely wants to actually do something that is more than bridging -- they probably want to be an access point (ala Apple's virtual airport functionality). The difference between that and just bridging is that the wireless clients can see each other with certainty (that is, no hidden node issues) and they can turn on power saving (that is, having the receiver duty cycle be less than 100%). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
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 storing stack pointers and the like in thread-specific data structures. -- +---++ | Chris Costello| A bug in the code is worth two | | [EMAIL PROTECTED] | in the documentation. | +---++ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
(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 setjmp/longjmp, and storing stack pointers and the like in thread-specific data structures. Ah, okay. Thanks. I use this approach, too, but not for threads; I relegate this type of architecture to state machines. I guess that cramming multiple threads into a single PID would be considered a state machine of sorts... Sounds like I need to just ignore libc_r and stick to syscalls and what I've been doing. I must note, however, that the uthreads source directory for libc_r provides a handy checklist of functions that might need a bit of TLC. :-) Thanks again, Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: fastforwarding?
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 normal (relatively slow) route lookup process. The packet flows directly from one layer2 input routine directly to the opposing layer2 output routine without traversing the IP layer. And more importantly, without traversing ipfw or ipfilter. In other words, don't use this on a firewall. Excellent point, grashopper. Perhaps we should collect this verbiage into the man page? Or, heaven forbid, stuff it into a comment in the code somewhere? Nah, that would be blasphemy. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Query: How to tell if Microsoft is using BSD TCP/IP code?
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
Re: fastforwarding?
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 process. The packet flows directly from one layer2 input routine directly to the opposing layer2 output routine without traversing the IP layer. And more importantly, without traversing ipfw or ipfilter. In other words, don't use this on a firewall. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
