Skip site navigation (1)Skip section navigation (2)
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>&quot;I'm not indecisive. Am I =
indecisive?&quot;</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <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: <http://docs.FreeBSD.org/cgi/mid.cgi?-253653191.980539550384.JavaMail.root>