Date: Fri, 26 Jan 2001 20:05:50 +0000 (GMT+00:00) From: postmaster@another.com To: hackers@FreeBSD.ORG Subject: Your message has been bounced by another.com Message-ID: <-253653191.980539550384.JavaMail.root@ad-a02.dmz.another.com>
next in thread | raw e-mail | index | archive | help
---433746122.980539550302.JavaMail.root.ad-a02.dmz.another.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, this is an automated message from another.com. We have tried to send your email to the address below, but we cannot find a user with that address. Please check the address of the person you are emailing and try again. moneytalks@showmethemoney.co.uk If you need further help, email us at support@another.com and a real, live human being will be happy to assist you. If you want to open your own another.com account then go to http://www.another.com/ Thanks, The another.crew ---433746122.980539550302.JavaMail.root.ad-a02.dmz.another.com Content-Type: message/rfc822 X-FunMail-size: 65807 X-Envelope-To: moneytalks@showmethemoney.co.uk Received: (qmail 9718 invoked from network); 26 Jan 2001 20:00:18 -0000 Received: from mx1.freebsd.org (216.136.204.125) by qm-a02 with SMTP; 26 Jan 2001 20:00:18 -0000 Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18])by mx1.FreeBSD.org (Postfix) with ESMTPid 1BC136E26EA; Fri, 26 Jan 2001 12:01:06 -0800 (PST) Received: by hub.freebsd.org (Postfix, from userid 538)id 7702B37B404; Fri, 26 Jan 2001 12:01:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1])by hub.freebsd.org (Postfix) with SMTPid 645F52E8193; Fri, 26 Jan 2001 12:01:05 -0800 (PST) Received: by hub.freebsd.org (bulk_mailer v1.12); Fri, 26 Jan 2001 12:01:05 -0800 From: owner-freebsd-hackers-digest@FreeBSD.ORG (freebsd-hackers-digest) To: freebsd-hackers-digest@FreeBSD.ORG Subject: freebsd-hackers-digest V5 #20 Reply-To: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers-digest@FreeBSD.ORG Precedence: bulk Message-ID: <bulk.29109.20010126120105@hub.freebsd.org> Date: Fri, 26 Jan 2001 12:01:05 -0800 (PST) freebsd-hackers-digest Friday, January 26 2001 Volume 05 : Number 020 In this issue: SYSINIT for userland? RE: SYSINIT for userland? Re: SYSINIT for userland? RE: SYSINIT for userland? Re: SYSINIT for userland? Re: SYSINIT for userland? NFS server out of mbuf's? Re: if_fxp driver info resource overheads 3ware ATA RAID 3DM management utility available Kernel Hacking (i tried not to make it lame) Re: if_fxp driver info Divert Sockets & Fragmentation revisited Re: Kernel Hacking (i tried not to make it lame) Re: Kernel Hacking (i tried not to make it lame) Re: Divert Sockets & Fragmentation revisited Re: Kernel Hacking (i tried not to make it lame) Re: Kernel Hacking (i tried not to make it lame) Re: FreeBSD Linux emulation / arla 0.34.6 Re: Kernel memory allocation bug ... RE: Kernel Hacking (i tried not to make it lame) Re: if_fxp driver info (which card then?) Re: if_fxp driver info (which card then?) Re: Divert Sockets & Fragmentation revisited Re: Divert Sockets & Fragmentation revisited gpc Pascal Compiler from FreeBSD Re: if_fxp driver info (which card then?) Re: if_fxp driver info (which card then?) Re: if_fxp driver info (which card then?) Re: if_fxp driver info (which card then?) [kernel patch] fcntl(...) to close many descriptors Re: [kernel patch] fcntl(...) to close many descriptors Re: Kernel memory allocation bug ... Re: Divert Sockets & Fragmentation revisited Re: pthreads and kqueue Re: NFS server out of mbuf's? Re: [kernel patch] fcntl(...) to close many descriptors packet redirection design problem [Divert Sockets & Fragmentation revisited] Re: [kernel patch] fcntl(...) to close many descriptors ---------------------------------------------------------------------- Date: Thu, 25 Jan 2001 11:52:53 -0800 From: Alfred Perlstein <bright@wintelcom.net> Subject: SYSINIT for userland? Has anyone done any work for FreeBSD or GNU C that allows for SYSINITs in userland, meaning just having to specify a function and arg to be called at a certain time during program startup? I know you can do some evil magic with overloading special shared object symbols, but it is evil magic. :) Anyone know of another OS that supports this? Any standards for it on the way? - -- - -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 12:07:54 -0800 (PST) From: John Baldwin <jhb@FreeBSD.ORG> Subject: RE: SYSINIT for userland? On 25-Jan-01 Alfred Perlstein wrote: > Has anyone done any work for FreeBSD or GNU C that allows for > SYSINITs in userland, meaning just having to specify a function > and arg to be called at a certain time during program startup? > > I know you can do some evil magic with overloading special shared > object symbols, but it is evil magic. :) > > Anyone know of another OS that supports this? Any standards for > it on the way? Use C++ with static instances of classes that have constructors. - -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 12:16:07 -0800 From: Alfred Perlstein <bright@wintelcom.net> Subject: Re: SYSINIT for userland? * John Baldwin <jhb@FreeBSD.ORG> [010125 12:09] wrote: > > On 25-Jan-01 Alfred Perlstein wrote: > > Has anyone done any work for FreeBSD or GNU C that allows for > > SYSINITs in userland, meaning just having to specify a function > > and arg to be called at a certain time during program startup? > > > > I know you can do some evil magic with overloading special shared > > object symbols, but it is evil magic. :) > > > > Anyone know of another OS that supports this? Any standards for > > it on the way? > > Use C++ with static instances of classes that have constructors. I've got a pretty good idea of how it could be done in C++. Have a global list that each object adds itself to in sorted order (via static constructor), the manipulation should be serialized, but this still isn't a solution for C. - -- - -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 15:16:09 -0500 (EST) From: "Alexander N. Kabaev" <ak03@gte.com> Subject: RE: SYSINIT for userland? Will functions marked with __attribute__((__constructor__)) or __attribute__((__destructor__)) satisfy your needs? Compiler will insert calls to these functions gets into .init section of the resulting ELF module which in turn will be called automatically at the program startup time. I do not remember exactly, but there might be even priority parameter you can specify with these attributes to manage the order in which these functions will be called. On 25-Jan-2001 Alfred Perlstein wrote: > Has anyone done any work for FreeBSD or GNU C that allows for > SYSINITs in userland, meaning just having to specify a function > and arg to be called at a certain time during program startup? > > I know you can do some evil magic with overloading special shared > object symbols, but it is evil magic. :) > > Anyone know of another OS that supports this? Any standards for > it on the way? > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message - ---------------------------------- E-Mail: Alexander N. Kabaev <ak03@gte.com> Date: 25-Jan-2001 Time: 15:10:40 - ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 12:19:59 -0800 From: Alfred Perlstein <bright@wintelcom.net> Subject: Re: SYSINIT for userland? * Alexander N. Kabaev <ak03@gte.com> [010125 12:16] wrote: > Will functions marked with __attribute__((__constructor__)) or > __attribute__((__destructor__)) satisfy your needs? > Compiler will insert calls to these functions gets into .init section of the > resulting ELF module which in turn will be called automatically at the program > startup time. I do not remember exactly, but there might be even priority > parameter you can specify with these attributes to manage the order in which > these functions will be called. Actually, the order can be kludged by just having these __constructors__ sort themselves into a list. Then all you need is a function call in main() to actually start these puppies up. :) It's still a bit off what I was looking for which would be putting these hooks into shared libaries hinged on pthread initialization, dns init, etc... - -- - -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 12:50:13 -0800 From: Mike Smith <msmith@freebsd.org> Subject: Re: SYSINIT for userland? > * Alexander N. Kabaev <ak03@gte.com> [010125 12:16] wrote: > > Will functions marked with __attribute__((__constructor__)) or > > __attribute__((__destructor__)) satisfy your needs? > > Compiler will insert calls to these functions gets into .init section of the > > resulting ELF module which in turn will be called automatically at the program > > startup time. I do not remember exactly, but there might be even priority > > parameter you can specify with these attributes to manage the order in which > > these functions will be called. > > Actually, the order can be kludged by just having these __constructors__ > sort themselves into a list. Then all you need is a function call > in main() to actually start these puppies up. :) > > It's still a bit off what I was looking for which would be putting > these hooks into shared libaries hinged on pthread initialization, > dns init, etc... You can actually do almost all of this with the ELF evilness that the loader uses (on i386) for doing its version of sysinits. Then you would just need to teach the C startup code to go looking for the appropriate section(s). - -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 16:12:10 -0500 From: Delanet Administration <admin@delanet.com> Subject: NFS server out of mbuf's? I run a FreeBSD 3.2s nfs server which recently crashed with a panic 'Out of mbuf clusters'. I found this odd since the normal peak is always below 200 and I compiled the kernel with users at 256 (4608 max mbufs). The server had an uptime of 118 days prior to this crash, and has no entries in the logs out of the norm up until this crash. Just curious if anyone knows of any reason this would happen? The server has no other use at all..no one even logs into it except me on occasion to go over logs and such. Thanks and regards, - -- - ------------------------------------------------------------ Stephen Comoletti - Network Engineer / Systems Administrator Delanet Inc. http://www.delanet.com Frontline Communications Corp. http://www.fcc.net phone: (302) 326-5800 fax: (302) 326-5802 x312 262 Quigley Blvd, New Castle, DE 19720, USA - ------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 19:55:04 -0500 From: Sergey Babkin <babkin@bellatlantic.net> Subject: Re: if_fxp driver info David Greenman wrote: > > >> I don't know what list you are looking at, but the download list that > >> I was > >>looking at did not include SCO, Unixware or any other Unix variant except > >>Linux. > > > >This is the list. > > > >NDIS2, NDIS3, NDIS4 and NDIS5 drivers > > Novell Netware* Client 3.11, 3.12 > > Novell Netware Server 4.1x, 5 > > SunSoft Solaris* > > SCO Unix 3, 5 > > SCO UnixWare* 2, 7, OpenDesktop*, OpenServer* > > > >These are "licensed" drivers. The linux driver is free. > > How do you know that the above drivers are developed by Intel? The above > could easily be OS vendor supplied. It's anybody's guess without the source. The drivers for SCO are developed by Intel, and bug reports are usually redirected to Intel. SCO just does build and packaging. If SCO produces some fixes, they are sent back to Intel as well. I get occasionally involved in this process and know for sure. Though I don't know if SCO pays anything to Intel for that, probably not, considering that Intel loans their hardware to SCO for free. These drivers contain some code ifdef-ed for Compaq and ICL builds, so I suppose Compaq and ICL also do their own packagind when they supply these drivers with UnixWare on their machines. - -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 17:09:02 -0800 From: vijay <vijay@IPRG.nokia.com> Subject: resource overheads Hi, I was wondering if there was any literature (maybe specific to FreeBSD or in general) about the overheads of various programming techniques etc. For eg, reducing the number of system calls, and mapping them to Library function calls, or say use of inline fucntions vs otherwise. v. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 18:25:04 -0800 From: Mike Smith <msmith@freebsd.org> Subject: 3ware ATA RAID 3DM management utility available (Please trim cc's on any followups to remove -hackers, thanks.) I'm happy to announce a quick public BETA cycle for the 3ware 3DM management utility for their family of ATA RAID controllers and FreeBSD. 3DM allows you to monitor and repair RAID arrays on 3ware controllers using a web browser, as well as generate email alerts on events and so forth. See http://www.3ware.com/products/3dm.shtml for more details. The product is not available in source form (sorry folks), but is compiled statically and should run on any FreeBSD system supporting the 3ware controllers (4.2 or later recommended). Thanks to 3ware for their support, and to my beta testers for their valuable input and persistence. - -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 22:03:35 EST From: GLOBALLINK2001@aol.com Subject: Kernel Hacking (i tried not to make it lame) hey guys i know you probably get this question all the time but i am looking into getting into doing somekernel hacking first i will tell you some thing i have assumed about it: 1.) you should know atleast more programming language well (probably C would be best) 2.) you should know some basic stuff about FreeBSD internels (i am planning on getting The Design and Implementation of the 4.4BSD Operating System that is about it the rest really is a blur and is so complex and huge i have no idea where to begin hope i wasn't to lame guys :-) Arthur To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 14:18:08 +1030 From: Greg Lehey <grog@lemis.com> Subject: Re: if_fxp driver info On Thursday, 25 January 2001 at 12:54:17 -0600, Jonathan Lemon wrote: > On Thu, Jan 25, 2001 at 01:12:42PM -0500, Dennis wrote: >> At 10:58 PM 01/24/2001, Jonathan Lemon wrote: >>> In article >>> <local.mail.freebsd-hackers/5.0.0.25.0.20010124170245.03bf6140@mail.etinc.com> >>> you write: >>>> >>>>> >>>>>> I'll look into the Linux driver, however, and see if it has anything >>>>>> useful in it. Historically the Linux Pro/100+ driver has totally >>> sucked and >>>>>> was chalk-full of magic numbers being anded and ored. >>>>> >>>>> That's "chock full", and you're confusing the Becker driver (bad) with >>>>> the Intel-supplied driver (slightly less bad). >>>> >>>> >>>> The intel driver seems to cover all the bases and has some nice glue >>>> routines for determining the part and features available. >>>> >>>> I havent tested it under load, but I wonder if intel would consider >>>> supporting it if someone ported it over to freebsd? they have drivers for >>>> just about every other major OS except BSD. it would be nice if the driver >>>> was updated BEFORE cards and MBs that dont work started showing up on the >>>> loading dock. Every time I get a shipment we have to hold our breath until >>>> we try one out. >>> >>> The documentation is available, if you want to (or have to) sign an >>> NDA. People who have the NDA documentation are perfectly capable of >>> writing a driver, although the source can't be released. It would >>> probably be possible to release a binary driver, but why do anything >>> to help Intel, given their unhelpful attitude? >> >> If they have a published, freely distributable driver for linux. why would >> you have to sign an NDA to port it to FreeBSD? >> >> I dont think so. Not anymore anyway. Thats the whole point of this thread... > > Having looked at the Linux driver, the FreeBSD driver, and the > documentation, I can tell you that assuredly not all of the features > are documented in the Linux driver. Also, porting requires changing > things, and without an understanding of _WHY_ things are done the > way they are, you can end up invaderdently changing something that > turns out to be critical. > > Also, the Intel driver isn't put together very well, so you might end > up with a lower performance driver after all is said and done. Performance isn't even the main thing. As I said earlier, it's plain bloody unreliable. Linux people avoid the EtherExpress because they think something is wrong with the card. They were surprised when I reported that it works without any problems under FreeBSD. Do we really want to change that? Greg - -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 22:59:27 -0500 (EST) From: Alwyn Goodloe <agoodloe@gradient.cis.upenn.edu> Subject: Divert Sockets & Fragmentation revisited Guys still having problems with divert sockets and fragmentation. As I said in a previous post the divert operations and corresponding program work fine when the datagram sent have size < MTU (1500) but when the datagram has size > MTU and hence get fragmented the recfrom just waits never receiving anything. I am attaching the relevent code fragments below. tcpdump tells me that the packets arrive on the interface. Hence I know the fragments arrive. Now my ipfw commands are: ipfw add 60000 divert 4422 udp from any to any 3322 in ipfw add 65000 allow ip from any to any Now I thought that that maybe the divert being so specific was a problem so I tried flushing ipfw and using the command: ipfw add 60000 divert 4422 ip from any to any thus diverting any ip packets and still nothing. Now according to the man page on divert: Incomming packets which get diverted are fully reassembled before delivery of any one fragment. Diversion of any one packet causes the entire packet to get diverted. I different fragments get diverted to different ports, then which port ultimately gets diverted is unpredictable. I was under the impression that the packets wern't reassemblembed before diversion. Am I wrong here? If the packets are reassembled before the diversion but as it says about that it may be unpredictable as to where they are sent could explain the case where I was redirecting udp packets heading toward 3322 but not the case where I was redirecting all IP packets. Any suggestions as to what stupid thing I have failed to do here. Alwyn Goodloe agoodloe@gradient.cis.upenn.edu Here is the important code fragments: Note: I have played with the MAX_PACKET_SIZE in hopes that it would make some difference but to no avail. #define MAX_PACKET_SIZE 300000 #define DIVERTPort 4422 #define ACTIVE_UDP_PORT 3322 if ((divert_sock = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) < 0) sys_error("divert socket error"); set_sock_data(&server_divert,PF_INET,DIVERTPort,INADDR_ANY); printf("Step 1 \n"); /* Register address and port with the system */ if (bind(divert_sock, (struct sockaddr*) &server_divert,sizeof(server_divert)) < 0) sys_error("server_divert bind error"); for ( ; ; ) { n = recvfrom (divert_sock,encaped_pkt,MAX_PACKET_SIZE,0, ( struct sockaddr * ) &client_add,&clilen); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 14:54:17 +1030 From: Greg Lehey <grog@lemis.com> Subject: Re: Kernel Hacking (i tried not to make it lame) On Thursday, 25 January 2001 at 22:03:35 -0500, GLOBALLINK2001@aol.com wrote: > hey guys i know you probably get this question all the time but i am looking > into getting into doing somekernel hacking first i will tell you some thing i > have assumed about it: > 1.) you should know atleast more programming language well (probably C would > be best) > > 2.) you should know some basic stuff about FreeBSD internels (i am planning > on getting The Design and Implementation of the 4.4BSD Operating System Correct on both counts. > that is about it the rest really is a blur and is so complex and > huge i have no idea where to begin hope i wasn't to lame guys :-) Well, once you have the book, look at something you might find interesting, and play around with it a bit. If you keep a "diary of a learning hacker" on the web, you might do a great favour to a number of people like yourself. If you run into trouble, ask here. Greg - -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 23:32:14 EST From: GLOBALLINK2001@aol.com Subject: Re: Kernel Hacking (i tried not to make it lame) so you mean like take one section at a time? like device drivers, smp etc? whatever catches my interest? ok i see just like programming when you got something big break it into parts, and wow can't belive the author of a great book and a core team member answered my question in less than an hour, try getting that from another OS :-) thanks greg! - -Arthur To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 01:02:33 -0500 From: "Patrick Bihan-Faou" <patrick@netzuno.com> Subject: Re: Divert Sockets & Fragmentation revisited Hi, Sorry to state something that is obvious, but when you bind your socket to the port, you have the port in the correct (network) order ? i.e. do you use htons(DIVERTPort) ? If you have lsof installed, run it and look at the port number that your program listens on. Patrick. > Here is the important code fragments: > > Note: I have played with the MAX_PACKET_SIZE in hopes that it would make some > difference but to no avail. > > #define MAX_PACKET_SIZE 300000 > #define DIVERTPort 4422 > #define ACTIVE_UDP_PORT 3322 > > > if ((divert_sock = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) < 0) > sys_error("divert socket error"); > set_sock_data(&server_divert,PF_INET,DIVERTPort,INADDR_ANY); > printf("Step 1 \n"); /* Register address and port with the system */ > if (bind(divert_sock, (struct sockaddr*) &server_divert,sizeof(server_divert)) < 0) > sys_error("server_divert bind error"); > for ( ; ; ) { > > n = recvfrom (divert_sock,encaped_pkt,MAX_PACKET_SIZE,0, > ( struct sockaddr * ) &client_add,&clilen); > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 01:10:53 -0800 From: Alfred Perlstein <bright@wintelcom.net> Subject: Re: Kernel Hacking (i tried not to make it lame) * GLOBALLINK2001@aol.com <GLOBALLINK2001@aol.com> [010125 19:04] wrote: > hey guys i know you probably get this question all the time but i am looking > into getting into doing somekernel hacking first i will tell you some thing i > have assumed about it: > 1.) you should know atleast more programming language well (probably C would > be best) C is necessary including a strong understanding of the pre-precessor, knowing a bit about 'make' is also pretty important. > 2.) you should know some basic stuff about FreeBSD internels (i am planning > on getting The Design and Implementation of the 4.4BSD Operating System Well more than 'basic' hopefully. :) Good choice on a book, others to look at are: "UNIX Internals 'the new frontiers'" Vahalia "The Basic Kernel Source Secrets" Jolitz and of course "The UNIX Hater's Handbook" > that is about it the rest really is a blur and is so complex and huge i have > no idea where to begin hope i wasn't to lame guys :-) Find a local user group, find and talk to some kernel hackers, but step away at the first sign of dizzyness or lightheadness. Feel free to ask on the mailing lists if something is confounding you, just be sure to check the mailing list archives first. best of luck, - -- - -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 17:30:15 +0800 From: Ariff Abdullah <skywizard@time.net.my> Subject: Re: Kernel Hacking (i tried not to make it lame) On Fri, 26 Jan 2001, you wrote: > * GLOBALLINK2001@aol.com <GLOBALLINK2001@aol.com> [010125 19:04] wrote: > > hey guys i know you probably get this question all the time but i am looking > > into getting into doing somekernel hacking first i will tell you some thing i > > have assumed about it: > > > 1.) you should know atleast more programming language well (probably C would > > be best) > > C is necessary including a strong understanding of the pre-precessor, > knowing a bit about 'make' is also pretty important. > > > 2.) you should know some basic stuff about FreeBSD internels (i am planning > > on getting The Design and Implementation of the 4.4BSD Operating System > > Well more than 'basic' hopefully. :) > > Good choice on a book, others to look at are: > "UNIX Internals 'the new frontiers'" Vahalia > "The Basic Kernel Source Secrets" Jolitz > and of course "The UNIX Hater's Handbook" > > > that is about it the rest really is a blur and is so complex and huge i have > > no idea where to begin hope i wasn't to lame guys :-) > > Find a local user group, find and talk to some kernel hackers, but > step away at the first sign of dizzyness or lightheadness. > > Feel free to ask on the mailing lists if something is > confounding you, just be sure to check the mailing list archives > first. > > best of luck, The manual pages are very helpfull although not the complete references, the sources itself is the saviour. I remembered porting back cd9660 to 2.2.x tree, and now look forward porting softupdates (If anybody can give me some light I really appreciate that). I'm reviewing sources from current, stable and from other BSD project such OpenBSD to pick all the good stuffs. I'm a happy 2.2.x user. - -- /\_____ / ./__ / __/ < I do understand.. / ___/ / / ^^^^^^^^^^^^^^^^^^^^^^ *warf* *warf* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 02:23:20 -0800 From: Kris Kennaway <kris@FreeBSD.ORG> Subject: Re: FreeBSD Linux emulation / arla 0.34.6 - --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 24, 2001 at 10:15:53PM -0600, Chris Csanady wrote: >=20 > >On Wed, Jan 24, 2001 at 12:50:29PM -0600, Chris wrote: > >> Silly me--I forgot to mention, this is with FreeBSD 4.2-STABLE. > > > >How recent -stable? A bug like this was fixed recently. If it's older > >than a week, Try upgrading :-) > > > >Kris >=20 > Hmm, are you referring to this commit? It appears to been MFC'd on > 11/07, so I hope not. :) I will rebuild and find out though.. That could be the one I'm thinking of. Kris - --=20 NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@FreeBSD.org - --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6cVAYWry0BWjoQKURAoTGAJ4uhJO2AXC342RXcSaeGIPYnurwbQCgw2IN QRwUt2uYTBlJenS0D/e6vgc= =gorV - -----END PGP SIGNATURE----- - --+QahgC5+KEYLbs62-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 11:30:45 +0100 From: Xavier Galleri <xgalleri@enition.com> Subject: Re: Kernel memory allocation bug ... Alfred Perlstein wrote: > * Xavier Galleri <xgalleri@enition.com> [010125 10:36] wrote: > >> Alfred Perlstein wrote: >> >>> I told you about 3 times to provide us with a stipped down source >>> code module which reproduces this "bug". >>> >>> You haven't done this. >>> >>> Therefore I can't help you. >>> >> I did not expect to make trouble to anyone, just sorry for the >> inconvenience ... I am not sure that we could easily provide for some >> code sample on this issue since this could be expensive, but I will see >> for sure (I easily understand that this is easier for anybody to track >> down a problem in such conditions ;-). >> >> That said, I still remain astonished not to get any comments or >> questions or hints or any other reactions about the analysis I have >> already provided. I have seen other mails in this list that exposed >> different kind of issues without requiring code sample to feed a >> constructive discussion. Did I miss something ? > > > You missed the two other people reporting "bugs" the same week you > began to. I spend a couple of hours trying to track them down and > they wound up being errors in thier code and not FreeBSD's. > > Honestly the symptoms you describe lean towards error on your part. > Even if they are not your error they seem pretty hard to reproduce. > > You've been complaining about this problem for at least a week. > Producing some code so that we can test couldn't take more than a > couple of hours and would have probably had your issue resolved > by now. > > This is why I'm irritated that you still haven't provided any code > to reproduce it. I wish I could avoid this misunderstanding ! The fact is that I was expecting some hints to track down the problem on myown, especially concerning the FreeBSD behaviour in case of free list shortage. Also, I would appreciate to know if my understanding of the figures I got from 'cnt' or of the scheduling behaviour with regard to kernel preemption is correct. I think this would be helpful for me to build the code sample you are requesting. > I do appreciate your mini-kernel debug howto, I've got it saved > for future reference. I am sincerely happy that I could provide something helpful ... Well, actually, it sounds that I did go to far to be able to retract myself, so I will let you know of any progress I will make asap ;-) Cheers, Xavier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 13:31:50 +0100 From: "Koster, K.J." <K.J.Koster@kpn.com> Subject: RE: Kernel Hacking (i tried not to make it lame) Dear Ariff, > > I remembered porting back cd9660 to 2.2.x tree, and now look > forward porting softupdates (If anybody can give me some light > I really appreciate that). I'm reviewing sources from current, > stable and from other BSD project such OpenBSD to pick all > the good stuffs. > I'm a happy 2.2.x user. > I think Yahoo! is using still on 2.2.8. There are some people on this list who work for Yahoo!, so you could try to drop them a line. I can imagine that they are interested in softupdates. Kees Jan ================================================ You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 08:51:32 -0500 (EST) From: Mike Wade <mwade@cdc.net> Subject: Re: if_fxp driver info (which card then?) On Fri, 26 Jan 2001, Greg Lehey wrote: > Performance isn't even the main thing. As I said earlier, it's plain > bloody unreliable. Linux people avoid the EtherExpress because they > think something is wrong with the card. They were surprised when I > reported that it works without any problems under FreeBSD. Do we > really want to change that? Slightly off subject but with all the discussion about not Intel playing nicely with the FreeBSD developers... I've always had the best reliability, performance, and lower CPU usage with the Intel EtherExpress Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there better cards out there that I should be looking at? - --- Mike Wade (mwade@cdc.net) Chief Technical Officer CDC Internet, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 09:47:38 -0500 (EST) From: Jim Sander <jim@federation.addy.com> Subject: Re: if_fxp driver info (which card then?) > > Linux people avoid the EtherExpress because they think something is > > wrong with the card. > Intel EtherExpress Pro 10/100B cards in FreeBSD These cards work well in our many 3.x and 4.x systems. But I just built up a Redhat 6.2 box with one, and all seemed to be working fine, but after a while I started having various problems starting net services. The box would boot, but often would "hang" indefinitely when "Starting eth0" - requiring a hard reboot. I swapped to another EE-Pro NIC, new MB, different RAM, other cables, everything, but no change. After I switched to a linksys NIC, voila- everything worked without a problem. (so far) Of course the Intel NICs still work perfectly when put into a spare BSD system. So it's *not* that the cards themselves are unreliable. Perhaps the drivers controlling them? Perhaps a weird MB/NIC conflict of some sort? - -=Jim=- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 10:01:41 -0500 (EST) From: Alwyn Goodloe <agoodloe@gradient.cis.upenn.edu> Subject: Re: Divert Sockets & Fragmentation revisited Thanks for the suggestion I will give lsof a shot to see. I think the port binding is correct, otherwise I don't think it would work when datagrams aren't fragmented. Like I said the code works fine for datagrams < MTU ==> not fragmented but fails when they are. That being said it NEVER HURTS TO CHECK. Alwyn agoodloe@gradient.cis.upenn.edu On Fri, 26 Jan 2001, Patrick Bihan-Faou wrote: > Hi, > > Sorry to state something that is obvious, but when you bind your socket to > the port, you have the port in the correct (network) order ? > > i.e. do you use htons(DIVERTPort) ? > > If you have lsof installed, run it and look at the port number that your > program listens on. > > > > Patrick. > > > > Here is the important code fragments: > > > > Note: I have played with the MAX_PACKET_SIZE in hopes that it would make > some > > difference but to no avail. > > > > #define MAX_PACKET_SIZE 300000 > > #define DIVERTPort 4422 > > #define ACTIVE_UDP_PORT 3322 > > > > > > if ((divert_sock = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) < 0) > > sys_error("divert socket error"); > > set_sock_data(&server_divert,PF_INET,DIVERTPort,INADDR_ANY); > > printf("Step 1 \n"); /* Register address and port with the system */ > > if (bind(divert_sock, (struct sockaddr*) > &server_divert,sizeof(server_divert)) < 0) > > sys_error("server_divert bind error"); > > for ( ; ; ) { > > > > n = recvfrom (divert_sock,encaped_pkt,MAX_PACKET_SIZE,0, > > ( struct sockaddr * ) &client_add,&clilen); > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 10:27:46 -0500 (EST) From: Alwyn Goodloe <agoodloe@gradient.cis.upenn.edu> Subject: Re: Divert Sockets & Fragmentation revisited Having run lsof I can verify that the program IS reading on that port number. Has anyone else on the hacker list had problems with diverting fragmented datagrams?? Alwyn Goodloe agoodloe@gradient.cis.upenn.edu On Fri, 26 Jan 2001, Patrick Bihan-Faou wrote: > Hi, > > Sorry to state something that is obvious, but when you bind your socket to > the port, you have the port in the correct (network) order ? > > i.e. do you use htons(DIVERTPort) ? > > If you have lsof installed, run it and look at the port number that your > program listens on. > > > > Patrick. > > > > Here is the important code fragments: > > > > Note: I have played with the MAX_PACKET_SIZE in hopes that it would make > some > > difference but to no avail. > > > > #define MAX_PACKET_SIZE 300000 > > #define DIVERTPort 4422 > > #define ACTIVE_UDP_PORT 3322 > > > > > > if ((divert_sock = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) < 0) > > sys_error("divert socket error"); > > set_sock_data(&server_divert,PF_INET,DIVERTPort,INADDR_ANY); > > printf("Step 1 \n"); /* Register address and port with the system */ > > if (bind(divert_sock, (struct sockaddr*) > &server_divert,sizeof(server_divert)) < 0) > > sys_error("server_divert bind error"); > > for ( ; ; ) { > > > > n = recvfrom (divert_sock,encaped_pkt,MAX_PACKET_SIZE,0, > > ( struct sockaddr * ) &client_add,&clilen); > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 10:38:24 -0500 From: "Person, Roderick" <personrp@ccbh.com> Subject: gpc Pascal Compiler from FreeBSD This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01C087AE.06D6891A Content-Type: text/plain; charset="iso-8859-1" Is anyone using this? I can seem to get the compiler to find any of the units. I have set the GPC_INCLUDE_DIR to where the units are but still no luck. Roderick P. Person Programmer II personrp@ccbh.com "I'm not indecisive. Am I indecisive?" - Jim Scheibel, mayor of St. Paul Minnesota - ------_=_NextPart_001_01C087AE.06D6891A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2650.12"> <TITLE>gpc Pascal Compiler from FreeBSD</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Is anyone using this?</FONT> </P> <P><FONT SIZE=3D2>I can seem to get the compiler to find any of the = units. I have set the GPC_INCLUDE_DIR to where the units are but still = no luck.</FONT></P> <P><FONT SIZE=3D2>Roderick P. Person</FONT> <BR><FONT SIZE=3D2>Programmer II</FONT> <BR><FONT SIZE=3D2>personrp@ccbh.com</FONT> </P> <BR> <P><FONT SIZE=3D2>"I'm not indecisive. Am I = indecisive?"</FONT> </P> <P> <FONT SIZE=3D2>- Jim = Scheibel, mayor of St. Paul Minnesota</FONT> </P> </BODY> </HTML> - ------_=_NextPart_001_01C087AE.06D6891A-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 19:43:10 +0300 (MSK) From: "Aleksandr A.Babaylov" <babolo@links.ru> Subject: Re: if_fxp driver info (which card then?) Mike Wade writes: > On Fri, 26 Jan 2001, Greg Lehey wrote: > > Performance isn't even the main thing. As I said earlier, it's plain > > bloody unreliable. Linux people avoid the EtherExpress because they > > think something is wrong with the card. They were surprised when I > > reported that it works without any problems under FreeBSD. Do we > > really want to change that? > Slightly off subject but with all the discussion about not Intel playing > nicely with the FreeBSD developers... I've always had the best > reliability, performance, and lower CPU usage with the Intel EtherExpress > Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there > better cards out there that I should be looking at? 3C905 - -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 12:20:25 -0500 From: Dennis <dennis@etinc.com> Subject: Re: if_fxp driver info (which card then?) At 08:51 AM 01/26/2001, Mike Wade wrote: >On Fri, 26 Jan 2001, Greg Lehey wrote: > > > Performance isn't even the main thing. As I said earlier, it's plain > > bloody unreliable. Linux people avoid the EtherExpress because they > > think something is wrong with the card. They were surprised when I > > reported that it works without any problems under FreeBSD. Do we > > really want to change that? > >Slightly off subject but with all the discussion about not Intel playing >nicely with the FreeBSD developers... I've always had the best >reliability, performance, and lower CPU usage with the Intel EtherExpress >Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there >better cards out there that I should be looking at? Why dont some people get the point even when you hit them in the head with a hammer? The point is that the driver quality is more important than the "card" To get completely off base, this is which is why we SELL our software. Implementation technique is usually more decisive in determining functionality and performance than the hardware itself. its something that people in the know are willing to pay for (sometimes). Certainly some hardware is better than others, but a bad driver with good hardware is useless. DB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 12:22:46 -0500 From: Dennis <dennis@etinc.com> Subject: Re: if_fxp driver info (which card then?) At 09:47 AM 01/26/2001, Jim Sander wrote: > > > Linux people avoid the EtherExpress because they think something is > > > wrong with the card. > > > Intel EtherExpress Pro 10/100B cards in FreeBSD > > These cards work well in our many 3.x and 4.x systems. > > But I just built up a Redhat 6.2 box with one, and all seemed to be >working fine, but after a while I started having various problems starting >net services. The box would boot, but often would "hang" indefinitely when >"Starting eth0" - requiring a hard reboot. I swapped to another EE-Pro >NIC, new MB, different RAM, other cables, everything, but no change. the eepro100 driver is badly broken in linux (havent you been paying attention?). it took me a few hours to fix it. They dont reset the card properly on an overrun, which causes it to lock up. Clearly the driver as is is unusable in a heavy use environment. DB > After I switched to a linksys NIC, voila- everything worked without a >problem. (so far) Of course the Intel NICs still work perfectly when put >into a spare BSD system. So it's *not* that the cards themselves are >unreliable. Perhaps the drivers controlling them? Perhaps a weird MB/NIC >conflict of some sort? > >-=Jim=- > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 12:25:32 -0500 From: Dennis <dennis@etinc.com> Subject: Re: if_fxp driver info (which card then?) At 11:43 AM 01/26/2001, Aleksandr A.Babaylov wrote: >Mike Wade writes: > > On Fri, 26 Jan 2001, Greg Lehey wrote: > > > Performance isn't even the main thing. As I said earlier, it's plain > > > bloody unreliable. Linux people avoid the EtherExpress because they > > > think something is wrong with the card. They were surprised when I > > > reported that it works without any problems under FreeBSD. Do we > > > really want to change that? > > Slightly off subject but with all the discussion about not Intel playing > > nicely with the FreeBSD developers... I've always had the best > > reliability, performance, and lower CPU usage with the Intel EtherExpress > > Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there > > better cards out there that I should be looking at? >3C905 I disagree. The if_fxp driver is far superior to the if_xl driver. In other OS's your mileage may vary. DB >-- >@BABOLO http://links.ru/ > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 19:32:34 +0100 From: mouss <usebsd@free.fr> Subject: [kernel patch] fcntl(...) to close many descriptors Hi, I've modified the kerenl to add F_CLOSEM functionality to fcntl. (I've seen this in some AIX docs). The purpose is allow a process to close all its filedescriptors starting from a given value without issuing thousands of close() syscalls. This may be used for programs that daemonize themselves (or one of their children) after some amount of work, when many fd's has been opened. The program would simply call fcntl(minclose, F_CLOSEM, 0); The patch concerns /sys/kern/kern_descriptors.c and fcntl.h (and of course the corresponding manpage). Is this functionality worth inclusion in the kernel (or should I throw away the patch)? are there any kind souls to review the patch? cheers, mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 10:33:44 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> Subject: Re: [kernel patch] fcntl(...) to close many descriptors I think it is worth doing. A quick google search shows that the linux folks discussed the AIX thingy in March 1999, but I don't think they actually implemented. From the discussion, it appears that the fcntl would be useful and (not having seen your patches), almost certainly trivial to implement. -Matt :Hi, : :I've modified the kerenl to add F_CLOSEM functionality to fcntl. :(I've seen this in some AIX docs). : :The purpose is allow a process to close all its filedescriptors starting :from a given value without issuing thousands of close() syscalls. :This may be used for programs that daemonize themselves (or one of :their children) after some amount of work, when many fd's has been :opened. The program would simply call : fcntl(minclose, F_CLOSEM, 0); : :The patch concerns /sys/kern/kern_descriptors.c and fcntl.h :(and of course the corresponding manpage). : :Is this functionality worth inclusion in the kernel (or should I throw :away the patch)? are there any kind souls to review the patch? : :cheers, :mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 19:36:15 +0100 From: Xavier Galleri <xgalleri@enition.com> Subject: Re: Kernel memory allocation bug ... This is a multi-part message in MIME format. - --------------010304000009040600000002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Xavier Galleri wrote: [...] >> You've been complaining about this problem for at least a week. >> Producing some code so that we can test couldn't take more than a >> couple of hours and would have probably had your issue resolved >> by now. >> >> This is why I'm irritated that you still haven't provided any code >> to reproduce it. > [...] > Well, actually, it sounds that I did go to far to be able to retract > myself, so I will let you know of any progress I will make asap ;-) Ok, I'm back again ;-) and this time, I got something for you ... Basically, what I did, is to write a little SYSCALL kld module to allow controlling calls to MALLOC/FREE from user space. This way, I can issue some filesystem-intensive command (tar something-bigger-than-memory-size) in order to create the free list shortage. Then, I use my test program to issue several MALLOC in kernel space. What I actually noticed is that, when the free list felt below 120 or alike, I can issue several thousands successful MALLOC as long as the asked size is no more than one or a few pages. But, when I ask for numerous pages (32Kb), then the process is falling asleep (this is analysed with my manual stack analysis process ;-), whilst the M_NOWAIT flag has been set (of course !). Everything is almost entirely self-documented in the attached kmem.tar.gz file. I hope this will help and I am eager to hear from you soon. Have a nice WE, Regards Xavier - --------------010304000009040600000002 Content-Type: application/gzip; name="kmem.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="kmem.tar.gz" H4sICEe+cToCA2ttZW0udGFyAO0ba1PbSJKv6Ff0kk2wWGH0sGUb1tkj4Gxxy+MKwt5tJZRL lkZGZ0vySbLBl/Dfr3tmZMsPSMgu3D6sCrKmp2emp9/TUnohC3fWnvaCil6rVmHNsKtGtSJ+ K/gLk0sHqJlWxTLtionPhmFatTWorj3DNUwzJwFYu+06/T5LgvvwEifyvLU/3dUj+Z/88q51 8W7ndyD/Ckoe5W+atrmS/3PLPxxnLM3K7m+9hqHrdqVyr/zNij6Rv2XoNZR/Ra9U10Bfyf/J L+VFELn9ocfg+zTzgrh8/XoW1A86BCsCx+kO/rnIrzls7MjGA5YugsPYG/bZ3ETh2EtGHIYy yAIXgiiDcCznbkfDcO+eriAKMiiN4sBTlY8KQJolQxcR+CptGgJ02+NdTlYesSQN4giakAb/ ZbFfIqhK3TiEnkv46weRV9rgRG2o2qspSpEimoJm9JzMKSNRI6e/p9wpygx9UKKmG3oap5vW FE/9OB4IiqmVsEzMjyu2naSbtjOgH9w18IcyTgG4Iv7s5SCaTO5jAqNpEUY/fCxOTCiCmNIM /Rq8oiF8Y4EPJURVYcCSJE5o7xJzQ83nGSaRoDPfoxNEYns4jauBe+0kW/Q8en8ldjaM0qAb MY93EelNfU9uWDBiQuasPEtiTSKKpv7eUrFFEwIMEhztlzY6jkdLgRsPo+xDtMF3AcBucfS2 wVt3NIdkG6fKuHqvX3FFEIxzsjgo8R7zio+QzJvCrStBSXoTZO41lHC2KSmukzLYDDd3C62T mVZnpvVGtsTo6VYmey+d7B8fnx1oLz38p+KmtAKbBCF0FfB/OTg5bMtRS3GJhcSCZpMohU+f IG+dbKrQSZjTA8G5uwKl/iYUCX+bN++n/O15q6U+lnAatByTE1aky2O+M+xny8m4jHpRfBOh LoQhuuZdeOlyGkha9015V1Bqnau0svYXv4rx/8TpMT/os2eO/5ju1+biv1Wr1Vbx/1niv0j6 diFP/qBcRn04PP95R4ZnZd11YfsMtgfBgE3RtmP5DNtH+ZCVOf1R7Z/k/Xs4/1cMvUrnP8Oy V+e/Z5b/U7n/L/D/xpz8LcRf+f9n8f8X5wcXTeHqXeWnk7ND0VB+Omt++5Had+VerPx0fEhd maKUJ8e3TuqVe3huKoe91yvP/8e3fxnv157d/i19kv9VdNsk+6+aq/zvmeo/eMoKIgbFY+V6 Sb89bO0fqnO9dHajvjet1ltVUajWg/2T6sukjjGpcMjCRX72z59FBeButvKBh7bpaqiP7f3z Hy/ap2+gJGs2RWx1RwJxOlVdeZ/fzv7dZ7d/26SYP2f/q/rv89d/7y/fDpzECZeAk9h9qNa7 UDNmUbYI77EkYv2l+Fm4pPY8CkOWsWTJwijBZQTlZN5TeubOa+B2ttAfucMEn/ZyqFyKfvcU KjdvbQFZTGfoQ5NKSIXytCL8E24xGaPPktPi0lsw0EAOHjqF+m866w/FMy/FipLpfGGYl7Xc eDCmEuwWTiWKuVpe1MZnVQWONS3W4RS7nKZdXgXUb1/eilLoS0+UPl96vG6Gg8u8Yk0PojxH T9MSXV4OlYhzJdFi+LivbkikCBntTrj4cgCC5/T0/qV3xYmRvZrs06DdPj46bbXbs0VOiaZK 0EdlXXAPWkenP+8f7ynrhQKgLP/RlVJ1fNCPGC86Pw2ZefVTDmtCrlqiAzWKYFGWAwTr8i1p Ql+0XARbUsQcrGon7cPWz28u3+LD6dk/94/ePdk2FrndbOoFhi9f7+3+0fHleSufeRf8hHGN uwkS/uu4WTDiT0E0fXYd95pJhVTWOZPKozaNbfOSvyYhNMssRMwxC8tnnoXyNQQIt7eOanBb otchE9U5PTtpndyrOn6cQIkkgiYq7Of7iZ0IwHffFdhTEPP6rITfE+6VkLM2sbllglXWC9wX w7gM1j8Sj75IACTqrxEC3xAXxbMIA2AqDoB5gUzK+et381IpmJmei2wy1YOWcXF5cNC6uChY yFfxKTchLvEnZtN9r0sKfpgS9Ye8MJFX9ArFPcwa/Tdf62MfaSgLKq4CbaJUch3PSzDhnzWb 3E7UhXWXjtKgMOABjvxxtaGQlcAj36gJeebi/OyLM47OX57J3EemOiK9k0mLbDR5rmNoeKOT WmlLnUmMZFqESUshd8Jz4exr/9j3U/5C+/SsffHLxQG60WWJVz92vEneJXLQLfrVYPIynq/G X5lPk7BJvjVJcZa88D05O2wfn+0fPmRTtP4uEBbQ606GDUm51ArRUvcetl9c6fL0y9YSeF+5 2m+rClIubST/8rgljuraK0GD9qqoE9pUWtrp5fExqfDqGP7/Pf+ft/YPT1pPtsbD53/DpJdD 4vxv1XTb4N//VY3V+f9Zzv/vMGyRM2ZpClmMlo0Nb+gyyERHp89CCFJwUgzpmDPdpLuKYmB0 DpKUfDMg29DFpulQDNkMnR7bzD/LSGEYeXiA5hUmQACIbw1gb1tVFFOFo4wmH6bMH/Zx/Zho uImTHobb7BocEMUBnNnJ4Bpp8Fhn2IV4kAVxlJJTmqErrygTDRKHmoetN5c/Nre7k/5CH+8/ fKMolgp/R2UAx6cTfxChXvT7QdTlu/JYihHby8mhjSSsE8dZjhBiUA4iRpGuwAxBGeHk/EAi X0Ov7/FoVay79WLsmPkQEzpQ0Rs2GLpZUWDx2vnAb8u6Pn3ityVd/OjP07G5q+T6ZRSefL2/ CfQmUJUcff/uGoV0E/T74AWYVztjSOOQ5WILUXecLkOewc7ISXb6cXdHwlINWDpgboC8HEty Nigd2iDBcX0ppke0LOt7pFabLjVnpCsrRbuwpKrhMeQn3xznGd8hZ9zcoPkTsZ4fiPVbt+6a DV3X4b1lX33VuEr18+NuXd2vMUJfNkHj3gnmU9PpRDJFNa26URVZqlWr6nmeathWY5qpmkat JnNVw3iQoR1Glf3PM3T2KDGlajneU+wC7YZc+K2PK213gu42qW6Ze/XZ6wXgmcSJxhCj4iVc w6nGyMJtzK1YlNLU0k41rpvd2OlDh3Ebf9A855ZxMWXKpAegTfUDRE+v4yQjMymXy8rC5380 lUZTqcr8B3aFrtd/GiMwrN/ICOREUn0MUxfKU7XsBkzURbcLymPqZiPXnppdfxorkGR9sRX8 +m3AV107nz585Uj49MiBS0zhmx++Ub7Arl6ACECYF2A8oDALbMQiDLpozFmAseZXGdXC+paJ DBVyXpiT94mRM8ThnoYYuaI4y09HmMmk1wxjJmZR4SDjJCo4aj9Dz0AjiAUaHKGbIVzyFi4m JXGfUbObOB0Ow+Qkn4HSDpFcOBy8OXCiwJ0kWzh9Fafn+YsbJwlzM5ml8JEyd3ETJ70GbxgO hJ+i7+I7Y9hMnRHDUWyTSKKkOOPpFWx2vQ5s9zYhxZBOyDwXc3hQxtDPaWWZIF8Yc0yeeJpU XifxsHtNk/FMiham+B6mXdT9wVyML/VwORUGsCX7lW8NPPp/xFY7dLp44m+ielRt3dSAYPKr bpRKpS4gOOgWIbZp2BNAgoBqTa9RekagQUYQCj513SKns3EQD8ZJ0L3OMBFSwWg0zG2TOig9 fouK++biEP6RxP9GnpY/RPPYtYaG97rO7xa/2/xe53fe2zD43eR3jtOofIg+ZLTCOeui20mJ L8Sjyyjg/2MhGxPkwOkHfpxEgVOGfVQnvnCKkk1ZMmIekpMTWCkb2+et4w3UtLuck7ewkxZ2 +h2xgbamCFilWrd2ZV6GbsT8ED0YV4RlTNxgjv2lAeVR+BhI7sX/XAD5EBETptq0cwtbpVLh XZ86HaAq35qkYghuu4nFFcN0PB+7NMJtMy/gQF9eEpoKqFs3GDIox+0MJNQ1Haa7OW4BijPn uLccmjcDiaQbDVs3KgLqJbpEUt7jlq7yPQWRH6NLddACp6sVRisXmeP2JAYa7BRpV4H5pSh1 D4N2/oqvXN7Bf+Qv+K2djiP3uuzu1qt1dQ/IUXh8CjFBtdapKrIKRZ5kYUmr/lnSrXpxMsIG ltG3yDiKPMdRJIKGJlxnHxUyzZ3m9JCV8i2Th5l6kodY9EKH4rZVIvqBvSv4xy3lPhw4RZc/ xKkotaRk0wvICcfJuLycnNltEzlZ2mdsAKXAQwtschv1DJ2RiiRBnKBLaKJi3GDI6/Jey/J9 y4CNURgPnGRDo3AYN/UHt1KxGwr+iRp/dB/acoptnVNsNhq+aXGKR2E77pBfbA8wnrUTFsaY npQETNDYqFrkG3lQaVatWg3jd+ThU72qgYvCjNpx1B/PkD0K8R+fsny9W63UFPwrMH+m+9F8 b7hyF3bFtvNdhM6g7bE+w8y9hM856Zho5aRbZsVE1eFOnDZAbdNs1OxFwnEC5LRRN3SFbvOE i+5H0+3WJd0Vu+NzuskjtoV7XEI1uuymSFjA7zvdtGksEEoiR1Is5AP+LXBYdj+aUl9qdp1Z Xo1TOm1ybyNJLpJIH58I+u1KnRzqIs1TLZUfexCP68ji5YY5QXos/b7pyrOpj+F7Qr9oEv0/ /ID+YvlQR5oIczp2dTJUNGmoTChNKPFxzY+Z3/bpk4QK2gU+s8KzV4TzMJTzypcBaNvQa7WG VTPMuiYTcurjYSjvwyF8RMDD0HbDtGt21aDwxlEpClE0l6vczq7i8m6rUjXoP2cLmEMwPI/w VpY4gygmJLNIQUIplinwebixa4atV7j1I8ylnVmG6OeCJpRqQ26tSL5lCPJTwYw78dpwohOB VbfFjSghjTBMW6HbVCUWcB6hEB2/4/udekWI0es4tYJUeZOk+q8gyvTbut6e/B9QUT0ThwPG QszYHF53SIMw6DsJr3RSKk0HgIzbxJgy+QH3QPwkwqJRkMRRSK/S+OlhP+IooUgWE/jPENEo J3fwrHjD+m7ME/JdyKvZf2NRQAhl7Fm9Z1ldq2t1ra7VtbpW1+paXatrda2uv/D1P0dA6cYA UAAA - --------------010304000009040600000002-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 10:43:00 -0800 (PST) From: Archie Cobbs <archie@dellroad.org> Subject: Re: Divert Sockets & Fragmentation revisited Alwyn Goodloe writes: > Guys still having problems with divert sockets and fragmentation. > > As I said in a previous post the divert operations and corresponding program > work fine when the datagram sent have size < MTU (1500) but when the > datagram has size > MTU and hence get fragmented the recfrom just > waits never receiving anything. I am attaching the relevent code > fragments below. > > tcpdump tells me that the packets arrive on the interface. > Hence I know the fragments arrive. > > Now my ipfw commands are: > > ipfw add 60000 divert 4422 udp from any to any 3322 in > ipfw add 65000 allow ip from any to any I think the problem is that the first fragment is matching your rule, but not subsequent fragments (because the port number is only contained in the first fragment..) > Now I thought that that maybe the divert being so specific was > a problem so I tried flushing ipfw and using the command: > ipfw add 60000 divert 4422 ip from any to any > > thus diverting any ip packets and still nothing. That doesn't make sense.. Try adding the "log" keyword to your ipfw commands, or checking the stats with "ipfw show" so you can see exactly what's being diverted. > Now according to the man page on divert: > > Incomming packets which get diverted are fully reassembled before > delivery of any one fragment. Diversion of any one packet causes > the entire packet to get diverted. I different fragments get > diverted to different ports, then which port ultimately gets > diverted is unpredictable. > > I was under the impression that the packets wern't reassemblembed before > diversion. Am I wrong here? Yes... but all fragments must match. - -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 11:12:59 -0800 (PST) From: Doug White <dwhite@resnet.uoregon.edu> Subject: Re: pthreads and kqueue On 25 Jan 2001, Kevin Mills wrote: > Well, there are wrappers in the libc_r code (libc_r/uthread/uthread_kevent.c) > and I seem to recall posts on -stable saying that kqueue could now be used > with user threads (around the 4.1.1 time frame, I think). I could be wrong :) > > This seems like a strange way to implement your solution, though ... from > > the sounds of it, you can only have one concurrent connection to your > > authentication server via this library, which sounds extremely lame. Do > > the clients just sit around forever until the server returns? The > > serialization this library forces isn't too scalable. > > The library is reentrant and will allow different threads to call into > it (there isn't a mutex serializing the entry point or anything like that). > However, the call to the backend is done with a blocking call. The > communication with the backend is generally very quick. However, if the > backend gets too busy I want to make sure I don't starve the other connections. > A thread pool seemed the best way to tackle this. I'd be very open to other > suggestions if you have any! Also, your proprietary library has to be threadsafe too. Particularly if it blocks... it'll probably block the whole process instead of the individual thread. Unless we figured out a way to fix that :) Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 11:19:14 -0800 (PST) From: Doug White <dwhite@resnet.uoregon.edu> Subject: Re: NFS server out of mbuf's? On Thu, 25 Jan 2001, Delanet Administration wrote: > I run a FreeBSD 3.2s nfs server which recently crashed with a panic 'Out > of mbuf clusters'. I found this odd since the normal peak is always > below 200 and I compiled the kernel with users at 256 (4608 max mbufs). > The server had an uptime of 118 days prior to this crash, and has no > entries in the logs out of the norm up until this crash. Just curious if > anyone knows of any reason this would happen? The server has no other > use at all..no one even logs into it except me on occasion to go over > logs and such. Sudden network outages during periods of high activity will cause mbuf cluser consumption to increase. 'netstat -m' is your friend. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 20:49:40 +0100 From: mouss <usebsd@free.fr> Subject: Re: [kernel patch] fcntl(...) to close many descriptors At 10:33 26/01/01 -0800, Matt Dillon wrote: > I think it is worth doing. A quick google search shows that > the linux folks discussed the AIX thingy in March 1999, but > I don't think they actually implemented. From the discussion, > it appears that the fcntl would be useful and (not having seen > your patches), almost certainly trivial to implement. you're right. (I can resend it as a tar file...) *** kern_descrip.c Fri Jan 26 19:42:18 2001 - --- kern_descrip.c.new Fri Jan 26 20:24:07 2001 *************** *** 364,369 **** - --- 364,387 ---- (caddr_t)(intptr_t)uap->arg, sizeof(fl)); } return(error); + + /* close all descriptors starting from a given value */ + case F_CLOSEM: + { + i = uap->fd; + + p->p_retval[0] = 0; + if ((unsigned)i >= fdp->fd_nfiles) { + return (EBADF); + } + for (; i<=fdp->fd_lastfile; i++) { + struct close_args uap; /* XXX. requires _SYS_SYSPROTO_H_ */ + uap.fd = i; + close(p, &uap); + } + return 0; + } + default: return (EINVAL); } The F_CLOSEM is added to <sys/fcntl.h> fcntl.diff *** fcntl.h Fri Jan 26 20:24:45 2001 - --- fcntl.h.new Fri Jan 26 20:25:39 2001 *************** *** 156,161 **** - --- 156,162 ---- #define F_GETLK 7 /* get record locking information */ #define F_SETLK 8 /* set record locking information */ #define F_SETLKW 9 /* F_SETLK; wait if blocked */ + #define F_CLOSEM 10 /* close open fd's larger >= arg */ /* file descriptor flags (F_GETFD, F_SETFD) */ #define FD_CLOEXEC 1 /* close-on-exec flag */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 21:00:54 +0100 From: mouss <usebsd@free.fr> Subject: packet redirection design problem [Divert Sockets & Fragmentation revisited] "IP filtering engines" that do something to packet based on rule matching have a problem when fragmentation comes to play. In the case of a "packet redirector' such as divert, the problem is that only the first fragment will match the rule, if the rule uses ports or whatever info contained in the payload. The problem occurs if the packet (that should match) is subject to change by the engine (either redirection, nat, blocking, ...) IP Filter handles such situation with specific code. It would be a nice thing if this is added to standard code so that packet filters writers do not need to add their own. Any opinions? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 12:00:17 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> Subject: Re: [kernel patch] fcntl(...) to close many descriptors : :At 10:33 26/01/01 -0800, Matt Dillon wrote: :> I think it is worth doing. A quick google search shows that :> the linux folks discussed the AIX thingy in March 1999, but :> I don't think they actually implemented. From the discussion, :> it appears that the fcntl would be useful and (not having seen :> your patches), almost certainly trivial to implement. : : :you're right. (I can resend it as a tar file...) : : :*** kern_descrip.c Fri Jan 26 19:42:18 2001 :--- kern_descrip.c.new Fri Jan 26 20:24:07 2001 :... Yah, something like that. You can test whether the descriptor is valid before calling close() on it, which should make it a lot faster. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ End of freebsd-hackers-digest V5 #20 ************************************ ---433746122.980539550302.JavaMail.root.ad-a02.dmz.another.com-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?-253653191.980539550384.JavaMail.root>