Re: Replacement for get_user_pages() of Linux
Thus spake Byunghyun Oh [EMAIL PROTECTED]: I'm porting Plex86 x86 VM, which uses get_user_pages() function at Linux-version kernel module to find and pin physical pages of memory in user space (according to its documentation). I tried many candidates as its replacement (PHYS_TO_VM_PAGE() macro in vm/vm_page.h seems most useful now), but they haven't worked at all. Any experience about porting VM-related things in Linux will be appreciated. :) Glancing at the Linux source, it looks like you want vm_map_wire(). BTW, in the future, it helps if you can describe what you're looking for, since we're not all Linux experts. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for get_user_pages() of Linux
David Schultz wrote: Thus spake Byunghyun Oh [EMAIL PROTECTED]: I'm porting Plex86 x86 VM, which uses get_user_pages() function at Linux-version kernel module to find and pin physical pages of memory in user space (according to its documentation). I tried many candidates as its replacement (PHYS_TO_VM_PAGE() macro in vm/vm_page.h seems most useful now), but they haven't worked at all. Any experience about porting VM-related things in Linux will be appreciated. :) Glancing at the Linux source, it looks like you want vm_map_wire(). BTW, in the future, it helps if you can describe what you're looking for, since we're not all Linux experts. I'm pretty sure this isn't what he really wants, it's just what he thinks he wants, and he's wrong about it, but he hasn't told us what problem he's trying to solve, so that we can correct his misconception. In general, FreeBSD drivers DMA to pages for which there is an established kernel mapping, period. With specific exceptions, kernel pages are not pageable, and so they do not need to be wired (you have to go way out of your way to get pageable kernel memory; most people don't do it, and I'm not even sure UMA allows you to get this type of memory any more). No FreeBSD driver DMA's into user space address space directly, bypassing kernel space address space; either there is a kernel mapping AND a user mapping, or there is ONLY a kernel mapping. The closest FreeBSD ever comes to this is to map a set of kernel space allocated pages into a user process address space, by the process opening a device node, and calling mmap() on it. In a pinch, you can force this on the process from kernel space, so you don't have to rewrite your code (e.g. the code is running under Linux or other emulation), but this is really frowned upon. In this case, the memory is usually allocated directly to the device at the time the device is attached, e.g. the video memory in a VGA card, or the memory window onto the AGP in the agpart device. Then it is mapped into the user process address space (e.g. the XFree86 server process), and DMAs into that memory are implicitly DMAs into the user process address space. Again, it would be really, really nice to know what problem he is trying to solve, so that people who know FreeBSD can tell him the FreeBSD way of solving the problem. I suspect that he wants to use bus_dmamem_alloc(), bus_dmamap_create(), bus_dma_tag_create(), etc., and write a standard FreeBSD device driver for his device, so that it will work on things like Alpha, SPARC64, IA64, PPC, and other platforms which care about memory windows onto main memory via bus space. Without knowing the problem he's trying to solve though... you get the point... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
bootp_subr.c forget it.
Thanks Terry Lambert, for your time. But i will not try help the FreeBSD community anymore... First of all, i have posted the diff file to you look the important parts, that construct my solution. NOt the constants ones... Of course that the FreeBSD code will not have my name, and company! That is the code that i did for MY company! What i wanted was share is the solution! If you will supress my name or everything, is not my problem. If i change a bit, a letter... in a source code, i will allways put my name. Not because the rights, but because the errors! Then i break the software, the errors are mine, this is justice. But the more important thing, is the idea, the solution. That i was trying to share. If someone like the solution, and implement it, is better for me, i'm not a devel man... Thanks again. [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: scan_ffs for UFS2
Michael Ranner (Sun, Feb 23, 2003 at 03:40:20PM +0100) wrote: Am Freitag, 21. Februar 2003 22:38 schrieben Sie: At 10:20 PM +0100 2/19/03, Michael Ranner wrote: For what it's worth, we (FreeBSD) have a simple SuperBlock recovery program in /usr/src/tools/tools/find-sb. I picked up some updates from Dave Cross for that, and have a few more of my own. I just have to sit down and get them all together into a single version. I don't know how find-sb compares to the program you're talking about, but they sound kind of similar. Scan_ffs can print the lost disklabel for use with disklabel(8). Find-sb, that version from cvs, seems only to print info about the superblocks of each file system and you have to rebuild the lost disklabel for your self. I was on the search for a simple tool for everybody, and found scan_ffs several months ago in the OpenBSD distribution (so it seems find-sb was like reinventing the wheel) and Robert Watson suggested in a posting december last year to adopt scan_ffs for UFS2. IMHO we should reuse a already written program with existing man pages, so we have the same sounding tools for the same tasks. I don't know what find-sb could do with your patches applied. If it's superior to scan_ffs, we can forget scan_ffs. FWIW, I did make scan_ffs work with UFS2 at one point in time, but I lost my stuff in a disk crash. It's a pretty good utility with good documentation. The only thing you need to worry about in the scan_ffs code is the opendisk() routine, or something like that, but it shouldn't be hard. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Monitoring changes in extended attributes?
On Wed, 12 Feb 2003, Kevin Fogleman wrote: Is there an existing way to monitor the entire filesystem for changes to any file, particularly changes in extended attributes? I'm looking to write a program that builds an index of all user-accessable extended attributes for every file in the filesystem and then updates that index in real time according to modifications to existing files' attributes, creation of new files and deletion of files. I've read over the documentation for kqueue, but some things were left unclear. For example, it appears that kqueue needs a file descriptor for each file that one would want to monitor, making any large-scale file monitoring impractical. Is there any other way in FreeBSD to be notified of file modifications in a way that would allow one to monitor the whole file system or large portions of it? Also, I'm not very knowledgable about file system conventions, so I'm wondering how one would detect the creation of new files? I don't really need to know whether a particular attribute changed, but rather just whether any of them changed. BTW, I have posted this question earlier to freebsd-questions, but nobody answered and, judging by the content of the other questions on that list, I thought that my question would be more appropriate here. Currently, you can monitor particular files for meta-data changes, which include extended attribute modifications, and you can monitor directories for changes, which might include the addition of a new name (and hence possibly a file). However, currently there's no way to monitor at the granularity of a file system for events such as Some EA changed or A new file was allocated. I guess such primitives haven't generally been needed in the past, although I can certainly imagine scenarios where they might be used. Kqueue is the vehicle the two events I identified above can be monitored with, and it's certainly possible to imagine adding new event categories to monitor a file system for global events, assuming it's a local file system. However, then the question becomes Once I know that a file has been added, how do I find it, which I would guess generally results in a recursive search, at which point I suspect you might as well just re-search the entire fs once in a while anyway. The functionality you're looking for sounds a bit more database-esque than in line with a traditional file store. FWIW, Apple has a searchfs() system call and vnode operation to permit more efficient meta-data searches on HFS+; this makes some sense for HFS+ because it has a notion of a centralized meta-data store, whereas ours is laid out pretty sparsely over the tree and works a bit differently. They don't support generalized meta-data extended attributes right now, though, although they do have a few specific attributes beyond the standard set. Well, we actually have local patches to add EA's to their UFS file system that would probably work on HFS+, but they aren't in the central Darwin tree. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C coding editor
Wes Peters wrote: Terminal? You have heard of this really cool thing called windowing software? ;^) I completely utterly fail to understand why some young developers attach some sort of romance to writing code on an 80x25 screen, when all the haxxors my age or older waited (or slaved away) for years, even decades, to get something better and more flexible. Terminal? 80x25 screen? Bloody luxury. How 'bout ed on a 300 baud DecWriter? You could even have more then 80 columns, if you had the wide paper :-) -stacy -- If they keep lowering education standards and raising the price of gasoline, there are going to be a lot of stupid people walking around. Stacy Millions [EMAIL PROTECTED] Millions Consulting Limited To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for get_user_pages() of Linux
I am so sorry that I couldn't (and maybe can't) explain what I want, because I don't know it exactly due to my poor knowledge of VM system and Plex86 itself (http://plex86.sourceforge.net/). But I'll try to explain here. Plex86 is a kind of VMWare or so, but it limits its focus to userland operation (many things had been said, but I only remember 'ring 3' and blah). Anyway, Plex86 originally allocated some memory places for some logging and VM guest's CPU info, and this allocation occured in kernel module. However, it changed to allocate in host application part, and kernel module just find user pages from their addresses (I'm not sure whether they are virtual or they are physical) and pin them (someone here already explained what pinning is). Of course, here is an un-pinning function also. I'm neither Linux expert nor FreeBSD expert, so I sought Linux-2.4.20 source, FreeBSD VM things, vmmon (VMWare kernel module part) for FreeBSD, and Google. However, I couldn't find no clear document and usage. Fortunately, many arguments from my question helped me so much, and I think its solution is so close. For now, thanks for answering my silly question. :) Byunghyun Oh octphial _at_ postech.ac.kr ps. Is DMA means just 'Direct Memory Access', and shall I understand it literally? On Mon, Feb 24, 2003 at 02:56:44AM -0800, Terry Lambert wrote: David Schultz wrote: Thus spake Byunghyun Oh [EMAIL PROTECTED]: I'm porting Plex86 x86 VM, which uses get_user_pages() function at Linux-version kernel module to find and pin physical pages of memory in user space (according to its documentation). I tried many candidates as its replacement (PHYS_TO_VM_PAGE() macro in vm/vm_page.h seems most useful now), but they haven't worked at all. Any experience about porting VM-related things in Linux will be appreciated. :) Glancing at the Linux source, it looks like you want vm_map_wire(). BTW, in the future, it helps if you can describe what you're looking for, since we're not all Linux experts. I'm pretty sure this isn't what he really wants, it's just what he thinks he wants, and he's wrong about it, but he hasn't told us what problem he's trying to solve, so that we can correct his misconception. In general, FreeBSD drivers DMA to pages for which there is an established kernel mapping, period. With specific exceptions, kernel pages are not pageable, and so they do not need to be wired (you have to go way out of your way to get pageable kernel memory; most people don't do it, and I'm not even sure UMA allows you to get this type of memory any more). No FreeBSD driver DMA's into user space address space directly, bypassing kernel space address space; either there is a kernel mapping AND a user mapping, or there is ONLY a kernel mapping. The closest FreeBSD ever comes to this is to map a set of kernel space allocated pages into a user process address space, by the process opening a device node, and calling mmap() on it. In a pinch, you can force this on the process from kernel space, so you don't have to rewrite your code (e.g. the code is running under Linux or other emulation), but this is really frowned upon. In this case, the memory is usually allocated directly to the device at the time the device is attached, e.g. the video memory in a VGA card, or the memory window onto the AGP in the agpart device. Then it is mapped into the user process address space (e.g. the XFree86 server process), and DMAs into that memory are implicitly DMAs into the user process address space. Again, it would be really, really nice to know what problem he is trying to solve, so that people who know FreeBSD can tell him the FreeBSD way of solving the problem. I suspect that he wants to use bus_dmamem_alloc(), bus_dmamap_create(), bus_dma_tag_create(), etc., and write a standard FreeBSD device driver for his device, so that it will work on things like Alpha, SPARC64, IA64, PPC, and other platforms which care about memory windows onto main memory via bus space. Without knowing the problem he's trying to solve though... you get the point... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
mysql endless loops
Hi! A known bug with MySQL 3.x is that it sometimes enters a 100% cpu usage loop if you stress it too much (I can repeat this every 2-3 weeks). I just attached a ktrace, and it shows this: 57486 mysqld CALL poll(0x8382000,0x4,0xb8c) 57486 mysqld RET poll 1 57486 mysqld CALL gettimeofday(0x283fddec,0) 57486 mysqld RET gettimeofday 0 57486 mysqld CALL poll(0x8382000,0x4,0xb8c) 57486 mysqld RET poll 1 57486 mysqld CALL gettimeofday(0x283fddec,0) 57486 mysqld RET gettimeofday 0 57486 mysqld CALL poll(0x8382000,0x4,0xb8c) 57486 mysqld RET poll 1 57486 mysqld CALL gettimeofday(0x283fddec,0) 57486 mysqld RET gettimeofday 0 57486 mysqld CALL poll(0x8382000,0x4,0xb8c) 57486 mysqld RET poll 1 57486 mysqld CALL gettimeofday(0x283fddec,0) 57486 mysqld RET gettimeofday 0 57486 mysqld CALL poll(0x8382000,0x4,0xb8c) 57486 mysqld RET poll 1 57486 mysqld CALL gettimeofday(0x283fddec,0) 57486 mysqld RET gettimeofday 0 57486 mysqld CALL poll(0x8382000,0x4,0xb8c) 57486 mysqld RET poll 1 57486 mysqld CALL gettimeofday(0x283fddec,0) 57486 mysqld RET gettimeofday 0 57486 mysqld CALL poll(0x8382000,0x4,0xb8c) 57486 mysqld RET poll 1 57486 mysqld CALL gettimeofday(0x283fddec,0) 57486 mysqld RET gettimeofday 0 57486 mysqld CALL poll(0x8382000,0x4,0xb8c) 57486 mysqld RET poll 1 57486 mysqld CALL gettimeofday(0x283fddec,0) 57486 mysqld RET gettimeofday 0 57486 mysqld CALL poll(0x8382000,0x4,0xb8c) 57486 mysqld RET poll 1 57486 mysqld CALL gettimeofday(0x283fddec,0) 57486 mysqld RET gettimeofday 0 57486 mysqld CALL poll(0x8382000,0x4,0xb8c) 57486 mysqld RET poll 1 ... (approx. 80 MB of these lines, then I killed the process). It seem the thread handling is broken for mysql (this gettimeofday happens in the while (select_thread_in_use) in mysqld.cc I believe. Anyways, I'm going to try mysql 4.0 now, maybe someone can use the information above. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C coding editor
Stacy Millions wrote: Wes Peters wrote: Terminal? You have heard of this really cool thing called windowing software? ;^) I completely utterly fail to understand why some young developers attach some sort of romance to writing code on an 80x25 screen, when all the haxxors my age or older waited (or slaved away) for years, even decades, to get something better and more flexible. Terminal? 80x25 screen? Bloody luxury. How 'bout ed on a 300 baud DecWriter? You could even have more then 80 columns, if you had the wide paper :-) Heh, I started with XEmacs on FreeBSD 2.0.5 and the first thing I did was resize the window so it was a full 800 pixels wide. This was a school assignment and we had to print out our programs to turn them in (with the disk, apparently they didn't trust those floppies). Turns out that my printer (an old 24 pin dot matrix deal[1]) only supported 80 columns, and I ended up wasting a LOT of paper (although the assignment was impressively thick when I turned it in. :) After that I relegated myself to never exceeding 80 columns unless absolutely necessary. [1] Kids these days have never overheated a printer in their life. -- \ |_ _|__ __|_ \ __| Jason Andresen[EMAIL PROTECTED] |\/ | ||/ _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for get_user_pages() of Linux
Byunghyun Oh wrote: ps. Is DMA means just 'Direct Memory Access', and shall I understand it literally? Yes, DMA stands for Direct Memory Access. The purpose of DMA is to allow devices other than the main CPU to directly access regions of physical memory by using a DMA line (DRQ) to arbitrate access to the physical memory bus, and then perform reads (DMA out) or writes (DMA in) to physical RAM belonging to system memory, rather than to the device. The reason to do permit this is so that the main CPU can keep processing whatever is in it's I and D (Instruction and Data) caches, without introducing a stall while the main CPU does its work. In this way, copy processing can be offloaded from the main CPU to chips on devices (DMA engines), instead. - In the context of Plex86, the reason for having this would be to permit physical devices to be assigned to the virtual machine, and not interact with the host system (I think). This idea ia somewhat flawed, and I don't think you can avoid the host system interaction. VMWare handles this by creating virtual hardware that then bridges to the real hardware (e.g. for serial ports and network adapters). In any case, what this would imply is that the kernel running under the Plex86 that has had the resource assigned to it would need *its* pages wired down, so that *its* driver(s) for the real hardware that has been assigned to it can pass kernel addresses to the DMA engines on the hardware, and have the hardware able to DMA into the kernel memory for the host OS. It seems to me that direct assignment of hardware resources is a bad idea, in this context, and that additional modifications to the hosted OS would be required in order to permit these addresses to be exported to real hardware, for DMA purposes. Specifically, you would need to translate from the virtual address to the physical address, given that the physical address is virtualized by the hardware, and this would not be automatic. A useful resource for someone porting Plex86 to FreeBSD is probably the NetBSD port of the code, back in December of last year (though the Plex86 web site claims that the code is significantly changed, as of February of this year, to mostly run in user space). See: http://slashdot.org/article.pl?sid=00/12/14/1041230 Also, FWIW, it looks like it already runs on FreeBSD?!?: http://savannah.nongnu.org/cgi-bin/viewcvs/plex86/plex86-release/kernel/host-freebsd.c http://savannah.nongnu.org/cgi-bin/viewcvs/*checkout*/plex86/plex86-release/kernel/host-freebsd.c?rev=1.1.1.1content-type=text/plain -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Exclusive Preview for Preferred Customers
Title: Chanintr exclusive Preview 01 WE ARE PLEASED TO ANNOUNCE THAT OUR NEWEST SHIPMENT HAS ARRIVED. PLEASE BE INVITED TO OUR EXCLUSIVE PREVIEW BETWEEN FEBRUARY 24 TILL MARCH 1, 2003. AS BEING OUR PREFERRED CUSTOMERS, YOU WILL BE THE FIRST TO BE INTRODUCED TO OUR NEWLY ADJUSTED PRICING (ON NEW ARRIVALS ONLY). FIND OUT MORE AT OUR SHOWROOM. RIBBON BOWS OFFERS BEAUTIFULLY CRAFTED BEDROOM FURNISHINGS THAT CAN ADAPT TO YOUR DEVELOPING CHILD'S NEEDS. 01.TWIN BED (PANEL HEADBOARD, FOOTBOARD, PANEL HEADBOARD RAILS) W104 H122cm Baht 24,940 02. NIGHT STAND W64 D43 H61cm Baht 16,340/pc 03. STUDENT DESK AND CHAIR ( DESK, HUTCH, CHAIR) W107 D48 H190cm Baht 58,910 04. TWIN BED WITH TRUNDLE FRONT (PANEL HEADBOARD,FOOTBOARD, PANEL HEADBOARD RAILS, TRUNDLE FRONT) W104 H122cm Baht 30,400 05. DRAWER CHEST W102 D48 H114cm Baht 36,120 06.SOFA BED A633-1180SL Lancaster Sleep Sofa Fabric No.: 1360-90 Gr. G W203 D91 H84cm Baht 132,000 ESPRESSO, A DARK RICH SATIN FINISH 07.1 SLAT HEADBOARD H127cm Baht 38,700 07.2 SLAT FOOTBOARD W71cm Baht 46,440 07 TOTAL SET: BAHT 85,140 08 NIGHT STAND W71 D45 H66cm Baht 30,315 /pc 09.1 MIRROR W101 D4 H111cm Baht 28,380 09.2 DRAWER DRESSER W162 D50 H100cm Baht 84,495 09 TOTAL SET: BAHT 112,875 MAPLE WOOD, CHERRY FINISH 10.SOFA TABLE W132 D40 H71cm Baht 35,475 11.SQUARE COCKTAIL TABLE W97 D97 H45cm Baht 38,700 12.BOOK TABLE W59 D50 H63cm Baht 35,475 /pc If you no longer wish to receive our mail please click here. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Properly reaping children from a fork()
I wasn't sure which group to send this too but -hackers seemed more
appropriate than -questions. I've started to play with sockets
under FreeBSD and have created a very simple server. All it does is
listens (on port 2525 by default) and when it receives a connection
fork()s. The only purpose it is accept a string, print it to stdout along
with the number of bytes received.
This is a first attempt for me but I seem to have problems when it comes
to ensuring that all the children exit like they should. What happens is
that each child process remains in a zombied state (as seen through ps).
Also if you check sockstat you can see that each zombied process still has
a connection open.
I'm not sure if the problem is how I am trying to close the socket or if
it is with my signal handling. I'm currently reading through intro(2) to
see if there is something simple I've missed.
I've attached the code for your enjoyment...I'm sure someone will be able
to point out my mistake pretty quickly. Also I've found a couple of web
pages that kind of explain socket handling but am looking for other
resources that I can consult.
Thanks in advance, I'm not a normal subscriber to -hackers so a cc to
[EMAIL PROTECTED] would be appreciated.
Regards
Gene Dinkey
[EMAIL PROTECTED]
--CUT HERE--
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include string.h
#include stdio.h
#include unistd.h
#include signal.h
#include sys/wait.h
#define MYPORT 2525
#define MAXRECV 5
#define MAXBUFSIZE 50
int main ( void );
int establish ( unsigned short portnum );
int get_connect ( int sockfd );
int get_data ( int sockfd );
void sigchld_handler ( int s );
int main ( void )
{
int s;
// struct sigaction sa;
if ((s=establish(MYPORT)) 0) //establish the socket
exit(-1);
s = get_connect(s); //wait for a
connection
/* The commented code was supposed to reap the children in but it didn't
the call to signal() is supposed to do the same thing, but it doesn't */
/* sa.sa_handler = sigchld_handler;
sigemptyset(sa.sa_mask);
sa.sa_flags = SA_RESTART;
if (sigaction(SIGCHLD, sa, NULL) == -1) {
perror(main:sigaction);
exit(-1);
} */
signal(SIGCHLD, sigchld_handler);
if (s != -1) {
get_data(s);// get the incoming data
close(s); // finally close the socket
}
exit(0);
}
/*handles zombied processes*/
void sigchld_handler ( int s )
{
while(waitpid(-1, NULL, WNOHANG) 0);
}
/* Establishses a socket and starts to listen */
int establish ( unsigned short portnum )
{
int sockfd;
struct sockaddr_in my_addr;
if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) 0) {//establish
the socket
perror(establish:socket);
return(-1);
}
/* host information */
my_addr.sin_family = AF_INET;
my_addr.sin_port = htons(portnum);
my_addr.sin_addr.s_addr = htonl(INADDR_ANY);
memset((my_addr.sin_zero), '\0', 8);
/* bid the socket to a port */
if (bind(sockfd, (struct sockaddr *) my_addr, sizeof(struct sockaddr)) 0) {
perror(establish:bind);
return(-1);
}
/* finally tell the socket to start listening */
if (listen(sockfd, MAXRECV) 0) {
perror(establish:listen);
close(sockfd);
return(-1);
}
return(sockfd); // return the socket handler
}
/*accepts connections*/
int get_connect ( int sockfd )
{
int sin_size, new_fd;
struct sockaddr_in their_addr;
sin_size = sizeof(struct sockaddr_in);
for(;;) { //begin the accept loop
/* accept the new connection and get the new socket id */
if ((new_fd = accept(sockfd, (struct sockaddr *)their_addr, sin_size)) 0) {
perror(get_connect:accept);
return(-1);
}
printf(Server got connection\n);
/* fork the new connection */
if(!fork()) {
close(sockfd); // close the listener, child doesn't need it
return(new_fd); // return the new active socket
}
}
return(-1);
}
/*gets some data and prints it out*/
int get_data ( int sockfd )
{
char buffer[MAXBUFSIZE];
int datain;
for (;;) { //begin the retreival loop
/* get the incoming data and check a few things */
if ((datain = recv(sockfd, buffer, MAXBUFSIZE, 0)) 0) {
perror(get_data:recv);
return(-1);
}
else if (datain 0) { //print number of bytes received
printf(Received
Re: Monitoring changes in extended attributes?
On Monday 24 February 2003 07:25, Robert Watson wrote: On Wed, 12 Feb 2003, Kevin Fogleman wrote: Is there an existing way to monitor the entire filesystem for changes to any file, particularly changes in extended attributes? I'm looking to write a program that builds an index of all user-accessable extended attributes for every file in the filesystem and then updates that index in real time according to modifications to existing files' attributes, creation of new files and deletion of files. I've read over the documentation for kqueue, but some things were left unclear. For example, it appears that kqueue needs a file descriptor for each file that one would want to monitor, making any large-scale file monitoring impractical. Is there any other way in FreeBSD to be notified of file modifications in a way that would allow one to monitor the whole file system or large portions of it? Also, I'm not very knowledgable about file system conventions, so I'm wondering how one would detect the creation of new files? I don't really need to know whether a particular attribute changed, but rather just whether any of them changed. BTW, I have posted this question earlier to freebsd-questions, but nobody answered and, judging by the content of the other questions on that list, I thought that my question would be more appropriate here. Currently, you can monitor particular files for meta-data changes, which include extended attribute modifications, and you can monitor directories for changes, which might include the addition of a new name (and hence possibly a file). However, currently there's no way to monitor at the granularity of a file system for events such as Some EA changed or A new file was allocated. I guess such primitives haven't generally been needed in the past, although I can certainly imagine scenarios where they might be used. Kqueue is the vehicle the two events I identified above can be monitored with, and it's certainly possible to imagine adding new event categories to monitor a file system for global events, assuming it's a local file system. However, then the question becomes Once I know that a file has been added, how do I find it, which I would guess generally results in a recursive search, at which point I suspect you might as well just re-search the entire fs once in a while anyway. The functionality you're looking for sounds a bit more database-esque than in line with a traditional file store. BeFS (in BeOS) had some interesting capabilities along these lines. It seems to me that the ability to monitor a mounted filesystem for inode changes would be a big plus. If you need to get from the inode number back to the filename or directory entry, you could either search or maintain an in-memory cache of the directory structure. -- 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: Properly reaping children from a fork()
On Mon, 24 Feb 2003, G-der wrote: I've attached the code for your enjoyment...I'm sure someone will be able to point out my mistake pretty quickly. Also I've found a couple of web pages that kind of explain socket handling but am looking for other resources that I can consult. You never establish the signal handler. Thanks in advance, I'm not a normal subscriber to -hackers so a cc to [EMAIL PROTECTED] would be appreciated. If you've got a bit of spare cash, you might want to peruse a couple of excellent texts: Advanced Programming in the Unix Environment (APUE) and Unix Network Programming (particularly volume 1); both by the late W. Richard Stevens. Well worth the money (and you'll probably receive several recommendations along the same lines). Cheers, jan -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ You know something's gone badly wrong when your algorithm takes O(n^2) time but uses O(2^n) space. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Properly reaping children from a fork()
Thank you everyone for your replies. The bug was a pretty silly one and one that I should have caught just stepping through the code. The call to signal() to install the handler was beging made after the fork(). So the children had a handler installed but not the parent. I moved the signal() call above the accept loop and before the fork and that seems to have cleared up that issue. Again, thanks for the prompt responses... Regards Gene Dinkey To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bootp_subr.c forget it.
On Monday 24 February 2003 08:48 am, Terry Lambert wrote: omestre wrote: Of course that the FreeBSD code will not have my name, and company! That is the code that i did for MY company! What i wanted was share is the solution! If you will supress my name or everything, is not my problem. If i change a bit, a letter... in a source code, i will allways put my name. Not because the rights, but because the errors! Then i break the software, the errors are mine, this is justice. The license issues are very serious to the community. FreeBSD could not, in good conscience, rip off your code without giving you the credit you asked for in your patch. We have other ways of noting donations to the project as well. The primary one is the Obtained From: header in the CVS commit, where sponsored changes like this can be noted without affecting the copyright in any way. Please consider using this if it is sufficient for you and your employers needs. I think that the community would be willing to take responsibility for any bugs that it was willing to commit to the source tree. Yes, we are, and we are also very willing to give credit. We don't want to create anymore licensing nightmare than we already have if we can avoid it. -- 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: Properly reaping children from a fork()
G-der wrote:
This is a first attempt for me but I seem to have problems when it comes
to ensuring that all the children exit like they should. What happens is
that each child process remains in a zombied state (as seen through ps).
Also if you check sockstat you can see that each zombied process still has
a connection open.
Unless you explicitly close the connection, it's open. In the case
of a zombie, though, there is a zombie status structure, and the files
are in fact closed. Probably what you are seeing is the TCP connection
is not being properly closed by the client, or the connection rate is
high enough that the 2MSL timer has not expired by the time you are
looking at it, so they appear open.
I'm not sure if the problem is how I am trying to close the socket or if
it is with my signal handling. I'm currently reading through intro(2) to
see if there is something simple I've missed.
Who is closing the socket, the client or the server? If the client
is closing the socket, it must call shutdown(2) on the socket, and
then explicitly call close. This is because certain user space TCP
implementations, such as those in Windows, do not have proper resource
tracking for sockets, which are implemented in user space, instead of
being implemented in kernel space.
There are also a number fo test applications, which are nothing
more than SYN-guns, i.e. they do not implement the full handshake,
and their only purpose is to connection-load the server. Many of
these send RST, and then drop all knowledge of the connection. This
will, over time, result in a large number of outstanding open sockets
on the server, since RST packets do not time out and repeat, since
they do not require ACK'ing: because of that, if they get lost, then
they are lost forever. This can happen even on a local wire, if you
get a collision or some other event (for example).
/* The commented code was supposed to reap the children in but it didn't
the call to signal() is supposed to do the same thing, but it doesn't */
/* sa.sa_handler = sigchld_handler;
sigemptyset(sa.sa_mask);
sa.sa_flags = SA_RESTART;
if (sigaction(SIGCHLD, sa, NULL) == -1) {
perror(main:sigaction);
exit(-1);
} */
signal(SIGCHLD, sigchld_handler);
This is bogus. You don't want SA_RESTART behaviour here, since it's
not like you have to worry about a system call. Calling the old
signal code overrides pretty much everything you do with the
sigaction() in any case.
Your main() exits, instead of hanging in wait() or sleep(), and
looping forever, in order to reap connections.
Your fork() returns the wrong way to main() (i.e. child exits and
parent stays around forever), so you have some identity confusion.
NB: An alternate way of setting up automatic reaping, since your
handler seems to not care about exit status, is to set SIG_IGN
as the handler for SIGCLD.
Actually, you'd do well to get a copy of UNIX Network Programming
by Stevens, or, minimally, download the example source code from
the publisher's web site. It would help you out by providing you
working simple server example source code.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
booting from Promise tx2000: FIXED
Since we only had one ATA133 on each TX2000 ATA channel, we skipped the TX2000 setup utility to define an array (we didn't want to run RAID or want any stinking arrays at all). We were able to boot from mobo ATA CDROM and install fbsd through the TX2000. ( btw, we always install fbsd boot mgr, since without the boot mgr, we more often than not, cannot get any boot at all ) But, no boot from TX2000 fbsd disk. Nothing, no errors, from TX200, nothing from fbsd bootblock. When we did define an array as span, but only had one disk per ATA channel in the span, we were finally able to get a boot but with a failure : Mounting Root from ufs:/dev/ad4s1a Root Mount Failed: 16 We figured the fbsd install pre-array/span wasn't accessible after we did defined array/span. So with the array mode + span now on, we re-installed fbsd via the TX2000 to the same disk. And now, we can boot just fine. while waiting for Soeren Schmidt to get the Promise SX4000 driver done! :)) Len To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: mysql endless loops
Hi Alex, This is a well known bug. You should consider to use linuxthreads. I hope it will be usable for 4.8R. Else look for patches at http://people.freebsd.org/~mbr/patches I run now all production servers with linuxthreads and hangs have gone. This document here describes the main problems with mysql on FreeBSD linked with libc_r: Short version of problems with native threading support (userland threads): 1. Non-thread safe DNS Lookups 2. Unfair Scheduling 3. High Load 4. No SMP Support 5. Missing Locks http://jeremy.zawodny.com/blog/archives/000203.html Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
