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 <[EMAIL PROTECTED]>
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 - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Thu, 25 Jan 2001 12:07:54 -0800 (PST)
From: John Baldwin <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> -- 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Thu, 25 Jan 2001 12:16:07 -0800
From: Alfred Perlstein <[EMAIL PROTECTED]>
Subject: Re: SYSINIT for userland?
* John Baldwin <[EMAIL PROTECTED]> [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 - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Thu, 25 Jan 2001 15:16:09 -0500 (EST)
From: "Alexander N. Kabaev" <[EMAIL PROTECTED]>
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 - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> "I have the heart of a child; I keep it in a jar on my desk."
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
- ----------------------------------
E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]>
Date: 25-Jan-2001
Time: 15:10:40
- ----------------------------------
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Thu, 25 Jan 2001 12:19:59 -0800
From: Alfred Perlstein <[EMAIL PROTECTED]>
Subject: Re: SYSINIT for userland?
* Alexander N. Kabaev <[EMAIL PROTECTED]> [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 - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Thu, 25 Jan 2001 12:50:13 -0800
From: Mike Smith <[EMAIL PROTECTED]>
Subject: Re: SYSINIT for userland?
> * Alexander N. Kabaev <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Thu, 25 Jan 2001 16:12:10 -0500
From: Delanet Administration <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Thu, 25 Jan 2001 19:55:04 -0500
From: Sergey Babkin <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Thu, 25 Jan 2001 17:09:02 -0800
From: vijay <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Thu, 25 Jan 2001 18:25:04 -0800
From: Mike Smith <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Thu, 25 Jan 2001 22:03:35 EST
From: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 14:18:08 +1030
From: Greg Lehey <[EMAIL PROTECTED]>
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/[EMAIL PROTECTED]>
>>> 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 [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Thu, 25 Jan 2001 22:59:27 -0500 (EST)
From: Alwyn Goodloe <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED]
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 14:54:17 +1030
From: Greg Lehey <[EMAIL PROTECTED]>
Subject: Re: Kernel Hacking (i tried not to make it lame)
On Thursday, 25 January 2001 at 22:03:35 -0500, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Thu, 25 Jan 2001 23:32:14 EST
From: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 01:02:33 -0500
From: "Patrick Bihan-Faou" <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 01:10:53 -0800
From: Alfred Perlstein <[EMAIL PROTECTED]>
Subject: Re: Kernel Hacking (i tried not to make it lame)
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [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 - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 17:30:15 +0800
From: Ariff Abdullah <[EMAIL PROTECTED]>
Subject: Re: Kernel Hacking (i tried not to make it lame)
On Fri, 26 Jan 2001, you wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 02:23:20 -0800
From: Kris Kennaway <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
- --+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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 11:30:45 +0100
From: Xavier Galleri <[EMAIL PROTECTED]>
Subject: Re: Kernel memory allocation bug ...
Alfred Perlstein wrote:
> * Xavier Galleri <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 13:31:50 +0100
From: "Koster, K.J." <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 08:51:32 -0500 (EST)
From: Mike Wade <[EMAIL PROTECTED]>
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 ([EMAIL PROTECTED])
Chief Technical Officer
CDC Internet, Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 09:47:38 -0500 (EST)
From: Jim Sander <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 10:01:41 -0500 (EST)
From: Alwyn Goodloe <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED]
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 [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
> >
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 10:27:46 -0500 (EST)
From: Alwyn Goodloe <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED]
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 [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
> >
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 10:38:24 -0500
From: "Person, Roderick" <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED]
"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>[EMAIL PROTECTED]</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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 19:43:10 +0300 (MSK)
From: "Aleksandr A.Babaylov" <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 12:20:25 -0500
From: Dennis <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 12:22:46 -0500
From: Dennis <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
>with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 12:25:32 -0500
From: Dennis <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
>with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 19:32:34 +0100
From: mouss <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 10:33:44 -0800 (PST)
From: Matt Dillon <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 19:36:15 +0100
From: Xavier Galleri <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 10:43:00 -0800 (PST)
From: Archie Cobbs <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 11:12:59 -0800 (PST)
From: Doug White <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED] | www.FreeBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 11:19:14 -0800 (PST)
From: Doug White <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED] | www.FreeBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 20:49:40 +0100
From: mouss <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 21:00:54 +0100
From: mouss <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
Date: Fri, 26 Jan 2001 12:00:17 -0800 (PST)
From: Matt Dillon <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
End of freebsd-hackers-digest V5 #20
************************************
