freebsd-hackers-digest V5 #260

[owner-freebsd-...@freebsd.org]

freebsd-hackers-digest Thursday, October 4 2001 Volume 05 : Number 260

In this issue:
Re: VM: file swapping (this time in libc): patch
Re: pkg_create help needed.
SIOCGIFDATA
Re: 4.3 vs 4.4
SIOCGIFDATA
hardware watch point support
Question about pthread
Re: Question about pthread
Re: Question about pthread
Re: Question about pthread
Re: 4.3 vs 4.4
if_sf bug
Re: if_sf bug
bluetooth
Re: setjmp/longjmp
Re: 4.3 vs 4.4
Re: bluetooth
Re: if_sf bug
Re: bluetooth
Re: bluetooth
Re: bluetooth
Re: hardware watch point support
4.2 pkg_add/pkg_delete inconsistency
Re: 4.3 vs 4.4
Re: bluetooth
Re: bluetooth
Re: bluetooth
Re: bluetooth
grep memory footage
Re: current strstr(3) implementation is slow
Re: VM: file swapping (this time in libc): patch
RE: [xine-user] xine on freebsd?
64bit Ethernet Card (if_sf driver)
Re: if_sf bug
Re: ALT-<sp> (Was: how to make 'for' understand two words as a singleargumen)
Re: Make a kernel in a different directory
Re: Make a kernel in a different directory
Re: if_sf bug
Re: grep memory footage
Re: grep memory footage
GA621 ?
Re: ALT-<sp> (Was: how to make 'for' understand two words as asingleargumen)

----------------------------------------------------------------------

Date: Wed, 3 Oct 2001 23:34:45 +0000
From: Vladimir Dozen <vladimi...@mail.ru>
Subject: Re: VM: file swapping (this time in libc): patch

ehlo.

> I once had a patch to phkmalloc() which backed all malloc'ed VM with
> hidden files in the users homedir. It was written to put the VM
> usage under QUOTA control, but it had many useful side effects as well.
>
> I can't seem to find it right now, but it is trivial to do: just
> replace the sbrk(2) with mmap(). Only downside is the needed
> filedescriptor which some shells don't like.

One small point -- machanical replace leads to segmentation faults
since brk(tail) expected always to allocate new block ending with tail;
while mmap can refuse to do it.

Actually, I repeated your work, and found that mmap() refused to map
block at 128M border; instead, it moved it somewhat higher. At the
same time, routines in libc/stdlib/malloc.c expected exactly the
same address they requested. I've patched them to get map address
from map_pages().

I've added new malloc configuration flag: 'F' (turn on file swapping) and
'f' (turn off). Then I've replaced brk/sbrk in code with mmap-based
emulations. It works. Currently whole my home host running with
'F' in /etc/malloc.conf.

I've tested it with famous 'life' game, and it showed that performance
with pure mmap() (not file swapping) increased a bit (about 2%) comparing
to original sbrk() implementation, and file swapping about 5% slower
than sbrk(). It depends on hardware, of course.

My implementation uses single file description, but dupes it to
512 (or less) to avoid problems with shells mentioned here. Mapped file
increased as neccessary and additional mmap()s called on it.

Here is patch for 4.3-RELEASE-p20:

/usr/src/libc/stdlib/malloc.c:
=============================================
100c100
<
- ---
>
248,250d247
< /* my last break. */
< static void *malloc_brk;
<
264a262
>
299a298,442
> * file swap options
> */
> static int malloc_file_swap;
> static char* malloc_file_swap_dir;
> static int malloc_file_swap_num;
> static int malloc_file_swap_fd;
> static int malloc_file_swap_offset;
> static int malloc_file_swap_size;
>
> /*
> * mmap-based brk/sbrk emulation
> */
> static char *malloc_brk;
> static char* sbrk_emulation(int incr)
> {
> if( incr == 0 ) return malloc_brk;
> wrterror("unsupported sbrk argument");
> };
>
> /**
> * brk emulation
> *
> * note that return value is different from brk!
> * @result 0 allocation failed, ptr -- start of new block
> * @param new_brk desired location of new top of heap
> *
> */
> static char* brk_emulation(char* new_brk)
> {
> char* p;
> char buf[4096];
> int filegrow,wr,blocksize;
> int stage;
> int tmp_fd;
>
> /* size of requested block */
> blocksize = new_brk-malloc_brk;
>
> /* increase heap size */
> if( blocksize > 0 )
> {
> if( malloc_file_swap )
> {
> /* create file at first call */
> if( malloc_file_swap_num == 0 )
> {
> /* where to put swap file */
> if( !malloc_file_swap_dir ) malloc_file_swap_dir = getenv("SWAPDIR");
> if( !malloc_file_swap_dir ) malloc_file_swap_dir = getenv("TMPDIR");
> if( !malloc_file_swap_dir ) malloc_file_swap_dir = "/tmp";
>
> /* generate random file name and open it */
> do
> {
> snprintf(buf,sizeof(buf),"%s/%08x.swap",
> malloc_file_swap_dir,malloc_file_swap_num);
> malloc_file_swap_num *= 11;
> malloc_file_swap_num += 13;
> malloc_file_swap_fd = open(buf,O_CREAT|O_EXCL|O_RDWR|O_NOFOLLOW,0600);
> }
> while( malloc_file_swap_fd < 0 && errno == EEXIST );
> if( malloc_file_swap_fd < 0 ) return 0;
>
> /*
> * some shell scripts (GNU configure?) can be
> * unhappy if we use descriptor 4 or 5; dup descriptor
> * into large enough descriptor and close original
> */
> tmp_fd = 512;
> while( tmp_fd >= 0 && dup2(malloc_file_swap_fd,tmp_fd) < 0 ) tmp_fd--;
> if( tmp_fd < 0 ) return 0;
> close(malloc_file_swap_fd);
> malloc_file_swap_fd = tmp_fd;
>
> /* unlink file to autoremove it at last reference lost */
> unlink(buf);
> }
>
> if( malloc_file_swap_offset+blocksize > malloc_file_swap_size )
> {
> /* fill tail of file with zeroes */
> memset(buf,0,sizeof(buf));
>
> /*
> * grow file
> * critical grow: if any error happens here, allocation fails
> * supplemental grow: errors are ignored
> */
> for( stage=0; stage<2; stage++ )
> {
> if( stage == 0 ) filegrow = blocksize;
> else filegrow = 1024*1024;
>
> while( filegrow > 0 )
> {
> /* note that file position is always at end of file */
> wr = write(malloc_file_swap_fd,
> buf,sizeof(buf)<filegrow?sizeof(buf):filegrow);
> if( wr < 0 )
> {
> if( errno == EINTR ) continue;
> if( stage == 0 ) return 0;
> break;
> }
> filegrow -= wr;
>
> /* keep file size for next time */
> malloc_file_swap_size += wr;
> }
> }
> }
>
> /* map file tail into address space */
> p = mmap(malloc_brk,blocksize,
> PROT_READ|PROT_WRITE,
> MAP_SHARED|MAP_NOSYNC|MAP_INHERIT,
> malloc_file_swap_fd,
> malloc_file_swap_offset);
> if( p == MAP_FAILED ) return 0;
>
> /* shift offset to use it next time in mmap */
> malloc_file_swap_offset += blocksize;
> }
> else
> {
> /* FIXME: we might use file swap if regular swapping failed;
> * but this may only happen when limit reached; should
> * we break limits with mmap()? */
> p = mmap(malloc_brk,new_brk-malloc_brk,
> PROT_READ|PROT_WRITE,
> MAP_ANON|MAP_PRIVATE,MMAP_FD,0);
> if( p == MAP_FAILED ) return 0;
> }
>
> malloc_brk = p+blocksize;
> return p;
> }
> else
> {
> /* here we must unmap memory */
> return 0;
> }
> }
>
> /*
307c450
< result = (caddr_t)pageround((u_long)sbrk(0));
- ---
> result = (caddr_t)pageround((u_long)sbrk_emulation(0));
310c453,454
< if (brk(tail)) {
- ---
> result = brk_emulation(tail);
> if( result == 0 ) {
315a460
> tail = result + (pages << malloc_pageshift);
318,321c463
< malloc_brk = tail;
<
< if ((last_index+1) >= malloc_ninfo && !extend_pgdir(last_index))
< return 0;;
- ---
> if ((last_index+1) >= malloc_ninfo && !extend_pgdir(last_index)) return 0;;
430a573,574
> case 'f': malloc_file_swap = 0; break;
> case 'F': malloc_file_swap = 1; break;
467c611
< malloc_origo = ((u_long)pageround((u_long)sbrk(0))) >> malloc_pageshift;
- ---
> malloc_origo = ((u_long)pageround((u_long)sbrk_emulation(0))) >> malloc_pageshift;
481c625
< * We can sbrk(2) further back when we keep this on a low address.
- ---
> * We can sbrk_emulation(2) further back when we keep this on a low address.
516c660
< if ((void*)pf->page >= (void*)sbrk(0))
- ---
> if ((void*)pf->page >= (void*)sbrk_emulation(0))
547,548d690
< size >>= malloc_pageshift;
<
550,551c692,693
< if (!p)
< p = map_pages(size);
- ---
> size >>= malloc_pageshift;
> if (!p) p = map_pages(size);
923c1065
< malloc_brk == sbrk(0)) { /* ..and it's OK to do... */
- ---
> malloc_brk == sbrk_emulation(0)) { /* ..and it's OK to do... */
932,933c1074,1075
< brk(pf->end);
< malloc_brk = pf->end;
- ---
> /* FIXME: here we must check returned address */
> brk_emulation(pf->end);
=============================================

- --
dozen @ home

------------------------------

Date: Wed, 03 Oct 2001 12:31:51 -0700
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: pkg_create help needed.

Julian Elischer wrote:
>
> I need to take a directory of 'stuff'
> which includes a script install.sh
> and make it into a package..
> I have had some success but it's not quite right..
>
> What I'd like to make it do is:
> unpack the 'stuff' into a temporary directory somewhere.
> run the install script
> delete the install directory
>
> The trouble is that I can't work out how to get the files
> unpacked there and have the install script get them from there..
>
> I can get it to unpack them into the final locations, and I can get the
> install script to run and find them there, but I need the install script
> to modify stuff and I'd rather have it all done in the temp
> directory if possible, and then istalled into the final
> location..
> also I have can not make the @srcdir option work in the packing list..
> does it work?
> (-s seems to work)

Use a preinstall script for the modifications. Yes, this
means you will need two scripts.

- -- Terry

------------------------------

Date: Wed, 3 Oct 2001 15:42:57 -0400
From: Kenneth Culver <cul...@yumyumyum.org>
Subject: SIOCGIFDATA

I was wondering if anyone had thought of implementing the above ioctl. Right
now from what I can tell, (from wmnet, and netstat) all stats for a network
device are kvm_read out of the kernel. On my local machine (just to see if it
was feasable) I wrote an ioctl and added a structure (nameifdata, which has a
character array to store an if_name, and an if_data) that when given an
if_name (in the nameifdata) it fills the if_data with the appropriate
device's stats, and pulls it back to userland. I was wondering if anyone
would be interested in committing this ioctl, mainly because for a program
such as wmnet or any other program that needs stats, it's a pain to go
through all the kvm stuff when a socket could just be opened, and then that
data could be ioctl'd using that socket.

If there is any reason why nobody has created this ioctl, please explain it
to me.

Ken

------------------------------

Date: Wed, 3 Oct 2001 15:59:02 -0400
From: Chris Faulhaber <jed...@fxp.org>
Subject: Re: 4.3 vs 4.4

- --8GpibOaaTibBMecb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 03, 2001 at 02:44:06PM -0400, Bsd...@aol.com wrote:
>=20
> Is there a delta/changes sheet in what 4.4 offers?=20
>=20

Try the release notes.

- --=20
Chris D. Faulhaber - jed...@fxp.org - jed...@FreeBSD.org
- --------------------------------------------------------
FreeBSD: The Power To Serve - http://www.FreeBSD.org

- --8GpibOaaTibBMecb
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: FreeBSD: The Power To Serve

iEYEARECAAYFAju7bgUACgkQObaG4P6BelBqKQCdEBWKDoqXM26TiCW5h910mcRh
5EoAnA1uar9sCgi/BY4tQ/kH/2sxCZdX
=qdka
- -----END PGP SIGNATURE-----

- --8GpibOaaTibBMecb--

------------------------------

Date: Wed, 3 Oct 2001 16:07:03 -0400 (EDT)
From: Garrett Wollman <wol...@khavrinen.lcs.mit.edu>
Subject: SIOCGIFDATA

<<On Wed, 3 Oct 2001 15:42:57 -0400, Kenneth Culver <cul...@yumyumyum.org> said:

> I was wondering if anyone had thought of implementing the above ioctl. Right
> now from what I can tell, (from wmnet, and netstat) all stats for a network
> device are kvm_read out of the kernel.

These applications should use sysctl instead. All of the information
is available through the interface mib.

- -GAWollman

------------------------------

Date: Wed, 3 Oct 2001 16:24:26 -0400 (EDT)
From: Zhihui Zhang <zzh...@cs.binghamton.edu>
Subject: hardware watch point support

Does FreeBSD 4.3-release support hardware watchpoint? If so, how to enable
it? I tried something like:

(gdb) watch * 0xc28374d0
Hardware watchpoint 4: * 3263395024
(gdb) watch * (int32_t *) 3263427792
Hardware watchpoint 5: *(int32_t *) 3263427792

But it does not seem to work well. Instead, I have to step through the
code to see when a memory value is changed.

Thanks,

- -Zhihui

------------------------------

Date: Thu, 04 Oct 2001 04:40:07 +0800
From: Oleg Golovanov <ol...@home.krasnoyarsk.ru>
Subject: Question about pthread

Dear Sirs:

I am using FreeBSD-2.2.8 and after calling pthread_create()
my programs get sigfault (SIGSEGV) and exited with core dump.

I should like to ask if somebody know the solve of this problem.
My example of using pthread is included below.

I ask to answer me directly on my e-mail.

Oleg

- ----

#include <errno.h>
#include <pthread.h>
#include <sys/socket.h>
#include <sys/un.h>

#define socklen_t unsigned int

static void *coms(void *arg)
{
pthread_detach(pthread_self());
write((int)arg, "Test", sizeof("test"));
close((int)arg);
return(NULL);
}

int main(int argc, char **argv)
{
int *confd, len, lisfd;
struct sockaddr_un *client, saun;

lisfd = socket(AF_UNIX, SOCK_STREAM, 0); unlink("/tmp/TS");
saun.sun_family = AF_UNIX; strcpy(saun.sun_path, "/tmp/TS");
bind(lisfd, (struct sockaddr *) &saun, sizeof(struct sockaddr_un));
listen(lisfd, 2);

client = (struct sockaddr_un *)malloc(sizeof(saun));
confd = (int *)malloc(sizeof(int));
for ( ; ; ) {
len = sizeof(saun);
*confd = accept(lisfd, (struct sockaddr *) client, &len);
pthread_create(NULL, NULL, &coms, confd);
}
return(0);
}

- ----

------------------------------

Date: Wed, 3 Oct 2001 16:09:52 -0500
From: Chris Costello <ch...@FreeBSD.ORG>
Subject: Re: Question about pthread

On Thursday, October 04, 2001, Oleg Golovanov wrote:
> static void *coms(void *arg)
> {
> pthread_detach(pthread_self());
> write((int)arg, "Test", sizeof("test"));
> close((int)arg);
> return(NULL);
> }

For starters, this function should be rewritten as

static void *coms(void *arg)
{
int fd;

fd = *(int *)arg;
pthread_detach(pthread_self());
write(fd, "Test", 4);
close(fd);
return (NULL);
}

Because you're passing the _address_ of `confd', not the
value. You must first cast arg to an int pointer, and then
dereference it (and assign its value to `fd').

- --
+-------------------+---------------------------------------------------+
| Chris Costello | CCITT - Can't Conceive Intelligent Thoughts Today |
| ch...@FreeBSD.org | |
+-------------------+---------------------------------------------------+

------------------------------

Date: Wed, 3 Oct 2001 16:13:26 -0500
From: Chris Costello <ch...@FreeBSD.ORG>
Subject: Re: Question about pthread

On Wednesday, October 03, 2001, Chris Costello wrote:
> Because you're passing the _address_ of `confd', not the

Er, sorry, `connfd' _is_ the address to a value (it's a
pointer). But you're still passing an address, and I believe
what I posted will solve the problem.

- --
+-------------------+---------------------------------------------------+
| Chris Costello | Implementation is the sincerest form of flattery. |
| ch...@FreeBSD.org | |
+-------------------+---------------------------------------------------+

------------------------------

Date: Wed, 3 Oct 2001 15:31:30 -0600
From: Chad David <dav...@acns.ab.ca>
Subject: Re: Question about pthread

On Thu, Oct 04, 2001 at 04:40:07AM +0800, Oleg Golovanov wrote:
> Dear Sirs:
>
> I am using FreeBSD-2.2.8 and after calling pthread_create()
> my programs get sigfault (SIGSEGV) and exited with core dump.
>
> I should like to ask if somebody know the solve of this problem.
> My example of using pthread is included below.
>
> I ask to answer me directly on my e-mail.
>
> Oleg
>
...
> pthread_create(NULL, NULL, &coms, confd);
...

I am not positive about 2.2.8, but I do not think you can
pass NULL as the first argument to pthread_create().

- --
Chad David dav...@acns.ab.ca
ACNS Inc. Calgary, Alberta Canada

------------------------------

Date: Wed, 3 Oct 2001 19:11:13 EDT
From: Bsd...@aol.com
Subject: Re: 4.3 vs 4.4

In a message dated 10/03/2001 3:55:16 PM Eastern Daylight Time,
tir...@users.sourceforge.net writes:

> > Is there a delta/changes sheet in what 4.4 offers?
>
> http://www.freebsd.org/releases/4.4R/notes.html
>
> or track the CVS tree :)
>

Thanks for the pointer, and not to the other fellow (jed...@fxp.org) who
chose to just make a snide remark.

B

------------------------------

Date: Wed, 3 Oct 2001 19:15:20 EDT
From: Bsd...@aol.com
Subject: if_sf bug

The if_sf driver doesnt seem to initialize itself until an address is set,
which makes things like tcpdump, bridging and other promiscuous things not
work.

Im sure B.P. will know where the safest place to put an sf_init to fix this
(I just stuffed one in on SIFFLAGS but it may not handle all cases.

Bryan

------------------------------

Date: Wed, 3 Oct 2001 17:14:08 -0700 (PDT)
From: Doug White <dwh...@resnet.uoregon.edu>
Subject: Re: if_sf bug

On Wed, 3 Oct 2001 Bsd...@aol.com wrote:

> The if_sf driver doesnt seem to initialize itself until an address is set,
> which makes things like tcpdump, bridging and other promiscuous things not
> work.

All the interfaces do that. If you want to make an invisible interface,
configure it with IP 0.0.0.0.

Doug White | FreeBSD: The Power to Serve
dwh...@resnet.uoregon.edu | www.FreeBSD.org

------------------------------

Date: Wed, 3 Oct 2001 17:42:07 -0700 (PDT)
From: John Kozubik <jo...@kozubik.com>
Subject: bluetooth

Is anyone working on bluetooth drivers and accompanying userland programs
(bluetooth equivalents of wicontrol, etc.) ?

I see nothing at freshmeat.net, release notes, or on related freebsd-*
lists. I have some free time in the next few months and would like to
work on them, but I would rather not duplicate anyones work.

- -----
John Kozubik - jo...@kozubik.com - http://www.kozubik.com

------------------------------

Date: Thu, 4 Oct 2001 10:29:13 +0930
From: Greg Lehey <gr...@FreeBSD.org>
Subject: Re: setjmp/longjmp

On Wednesday, 3 October 2001 at 12:12:14 -0700, Julian Elischer wrote:
> I suppose it must have been Peter Penchev who wrote:
>> On Wednesday, October 03, 2001 6:14 AM, Greg Lehey <gr...@FreeBSD.org> wrote:
>>> On Tuesday, 2 October 2001 at 12:43:54 -0700, Julian Elischer wrote:
>>>> On Tue, 2 Oct 2001, Peter Pentchev wrote:
>>>>> On Mon, Oct 01, 2001 at 10:56:24AM +0930, Greg Lehey wrote:
>>>>>> [Format recovered--see http://www.lemis.com/email/email-format.html]
>>>>>>
>>>>>> On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote:
>>>>>>> On Fri, 28 Sep 2001, Gersh wrote:
>>>>>>>> On Fri, 28 Sep 2001, Bernd Walter wrote:
>>>>>>>>> On Fri, Sep 28, 2001 at 07:03:51PM +0530, Anjali Kulkarni wrote:
>>>>>>>>>> Does anyone know whether it is advisable or not to use
>>>>>>>>>> setjmp/longjmp within kernel code? I could not see any
>>>>>>>>>> setjmp/longjmp in kernel source code. Is there a good reason for
>>>>>>>>>> this or can it be used?
>>>>>>>>>
>>>>>>>>> You need to look again, it's used in several places in the kernel.
>>>>>>>>
>>>>>>>> Look at sys/i386/i386/db_interface.c
>>>>>>>
>>>>>>> Yeah but it would probably be a pretty bad idea to use it without
>>>>>>> very careful thought. Especialy with the kernel becoming
>>>>>>> pre-emptable in the future..
>>>>>>
>>>>>> Can you think of a scenario where it wouldn't work? Preemption
>>>>>> doesn't tear stacks apart, right?
>>>>>
>>>>> How about a case of a longjmp() back from under an acquired lock/mutex?
>>>>> Like function A sets up a jump buffer, calls function B, B acquires
>>>>> a lock, B calls C, C longjmp()'s back to A; what happens to the lock?
>>>>>
>>>>> It would work if A were aware of B's lock and the possibility of a code
>>>>> path that would end up with it still being held; I presume that this is
>>>>> what Julian meant by 'very careful thought'.
>>>>
>>>> pretty much...
>>>
>>> That's wrong, of course, but I don't see what this has to do with
>>> preemptive kernels. This is the same incorrect usages as performing
>>> malloc() and then longjmp()ing over the free().
>>
>> Right, that was my question too, doesent seem connected with pre-emptive
>> kernels...
>
> basically it's just that pre-emtion just muddies the waters more..

Or statements which aren't backed up with examples?

Greg
- --
See complete headers for address and phone numbers

------------------------------

Date: Wed, 03 Oct 2001 19:03:45 -0600
From: Warner Losh <i...@harmony.village.org>
Subject: Re: 4.3 vs 4.4

In message <152.1f6c31...@aol.com> Bsd...@aol.com writes:
: Is there a delta/changes sheet in what 4.4 offers?

http://www.freebsd.org/ has a link to the release notes.

Warner

------------------------------

Date: Wed, 03 Oct 2001 19:08:58 -0600
From: Warner Losh <i...@harmony.village.org>
Subject: Re: bluetooth

In message <Pine.BSF.4.21.011003...@www.kozubik.com> John Kozubik writes:
: Is anyone working on bluetooth drivers and accompanying userland programs
: (bluetooth equivalents of wicontrol, etc.) ?

I tried to get a bluetooth pcmcia card, but I haven't been able to win
one on ebay or find one availble through more normal channels.

I've also had no luck finding datasheets on the bluetooth stuff, but
to be honest I haven't tried too hard.

Warner

------------------------------

Date: Wed, 3 Oct 2001 21:23:40 EDT
From: Bsd...@aol.com
Subject: Re: if_sf bug

In a message dated 10/03/2001 8:14:30 PM Eastern Daylight Time,
dwh...@resnet.uoregon.edu writes:

> > The if_sf driver doesnt seem to initialize itself until an address is set,
> > which makes things like tcpdump, bridging and other promiscuous things
not
> > work.
>
> All the interfaces do that. If you want to make an invisible interface,
> configure it with IP 0.0.0.0.
>

They dont "all do that". the fxp and dc drivers work fine when setting
promiscuous mode from within the kernel,the sf doesnt.

------------------------------

Date: Wed, 3 Oct 2001 19:07:42 -0700 (PDT)
From: John Kozubik <jo...@kozubik.com>
Subject: Re: bluetooth

I had a feeling if anyone was looking into it that you were - if nobody
else is looking at it, I'll start working. I have a 3com and a xircom.
Please keep this in mind if you hear of anyone on (or starting on) a
similar track, and I will watch -mobile.

- -----
John Kozubik - jo...@kozubik.com - http://www.kozubik.com

On Wed, 3 Oct 2001, Warner Losh wrote:

> In message <Pine.BSF.4.21.011003...@www.kozubik.com> John Kozubik writes:
> : Is anyone working on bluetooth drivers and accompanying userland programs
> : (bluetooth equivalents of wicontrol, etc.) ?
>
> I tried to get a bluetooth pcmcia card, but I haven't been able to win
> one on ebay or find one availble through more normal channels.
>
> I've also had no luck finding datasheets on the bluetooth stuff, but
> to be honest I haven't tried too hard.
>
> Warner
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>

------------------------------

Date: Wed, 03 Oct 2001 19:16:30 -0700
From: Maksim Yevmenkin <myev...@digisle.net>
Subject: Re: bluetooth

> Is anyone working on bluetooth drivers and accompanying userland programs
> (bluetooth equivalents of wicontrol, etc.) ?

ok :) i'm actually working on BlueTooth stack for FreeBSD. so far
i have some code that implements basic functionality for HCI layer.
the implementation is based on Netgraph and supposed to be completely
optional.

thanks,
max

------------------------------

Date: Wed, 03 Oct 2001 20:35:14 -0600
From: Warner Losh <i...@harmony.village.org>
Subject: Re: bluetooth

In message <Pine.BSF.4.21.011003...@www.kozubik.com> John Kozubik writes:
: I had a feeling if anyone was looking into it that you were - if nobody
: else is looking at it, I'll start working. I have a 3com and a xircom.
: Please keep this in mind if you hear of anyone on (or starting on) a
: similar track, and I will watch -mobile.

Will do.

Warner

------------------------------

Date: Wed, 3 Oct 2001 22:59:45 -0400
From: Brian Dean <b...@bsdhome.com>
Subject: Re: hardware watch point support

Seems to work ok for a simple test case I just tried with 4-STABLE
(post 4.4-RELEASE). I don't have a 4.3-RELEASE box to test, but it
should work there too.

- -Brian

On Wed, Oct 03, 2001 at 04:24:26PM -0400, Zhihui Zhang wrote:

> Does FreeBSD 4.3-release support hardware watchpoint? If so, how to enable
> it? I tried something like:
>
> (gdb) watch * 0xc28374d0
> Hardware watchpoint 4: * 3263395024
> (gdb) watch * (int32_t *) 3263427792
> Hardware watchpoint 5: *(int32_t *) 3263427792
>
> But it does not seem to work well. Instead, I have to step through the
> code to see when a memory value is changed.
>
> Thanks,
>
> -Zhihui

------------------------------

Date: Wed, 3 Oct 2001 22:12:32 -0700 (PDT)
From: Romain Kang <rom...@kzsu.stanford.edu>
Subject: 4.2 pkg_add/pkg_delete inconsistency

Has anyone else noticed the following inconsistency?

Some packages have been having problems related to @exec and @unexec
statements and the %D sequence. I think this happens because
contrary to the pkg_create man page, it appears that %D is expanded
for @exec, but not for @unexec. (This seems to be a pkg_delete
bug, but I haven't been able to look in the FreeBSD CVS server to
figure out if/when @unexec last supported %D).

@exec needs an absolute pathname, and using %D fulfill this
requirement. @unexec commands take place in the directory specfied
by @cwd, so leaving off %D seems to be the easiest way for @unexec
to access paths that were set up by @exec.

To use an example from the database package:
@cwd /usr
...
npdatabase/dbcheck
...
@exec ln -sf %D/npdatabase/dbcheck %D/local/etc/rc.d/dbcheck.sh
@unexec rm -f local/etc/rc.d/dbcheck.sh

When the package is added:
- npdatabase/dbcheck is installed as /usr/npdatabase/dbcheck
- /usr/npdatabase/dbcheck is linked to /usr/local/etc/rc.d/dbcheck.sh

When the package is deleted:
- /usr/local/etc/rc.d/dbcheck.sh is removed

Both @exec and @unexec could use just absolute pathnames
(/usr/local/etc/rc.d/dbcheck.sh), but this would prevent
relocation of the package. It's not important at the moment,
but package relocation could be used in the future to help
generate system disk images on manufacturing stands without
disturbing the manufacturing machine's installed software.

Regards,
Romain Kang Disclaimer: I speak for myself alone,
rom...@kzsu.stanford.edu except when indicated otherwise.

------------------------------

Date: Thu, 4 Oct 2001 01:40:57 -0500
From: Will Andrews <wi...@physics.purdue.edu>
Subject: Re: 4.3 vs 4.4

On Wed, Oct 03, 2001 at 07:11:13PM -0400, Bsd...@aol.com wrote:
> Thanks for the pointer, and not to the other fellow (jed...@fxp.org) who
> chose to just make a snide remark.

Snide? That's what you call snide? Wow, I'd hate to hear what
you consider only to be the doing of a true jerk. Next time if
you don't know where something is just ask, don't be a blue meanie
like this to someone who was only trying to help. Geez. What's
happened to courtesy in this world...!?

- --
wca

------------------------------

Date: Thu, 4 Oct 2001 08:49:46 +0200
From: "Nicolai Petri" <fre...@petri.cc>
Subject: Re: bluetooth

Hi Warner,

I've seen cards for sale on http://www.digianswer.dk (Motorola's Bluetooth
center), the price is 200$ for a retail pccard.

Best regards,
- - Nicolai Petri

- ----- Original Message -----
From: "Warner Losh" <i...@harmony.village.org>
To: "John Kozubik" <jo...@kozubik.com>
Cc: <freebsd...@FreeBSD.ORG>
Sent: Thursday, October 04, 2001 3:08 AM
Subject: Re: bluetooth

> In message <Pine.BSF.4.21.011003...@www.kozubik.com> John
Kozubik writes:
> : Is anyone working on bluetooth drivers and accompanying userland
programs
> : (bluetooth equivalents of wicontrol, etc.) ?
>
> I tried to get a bluetooth pcmcia card, but I haven't been able to win
> one on ebay or find one availble through more normal channels.
>
> I've also had no luck finding datasheets on the bluetooth stuff, but
> to be honest I haven't tried too hard.
>
> Warner
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message

------------------------------

Date: Thu, 04 Oct 2001 08:34:39 +0100 (BST)
From: Duncan Barclay <dm...@dmlb.org>
Subject: Re: bluetooth

Hi

I might be worth talking to the people at

http://www.blueaid.com/

Bill Munday has written and architected a number of the Bluetooth stacks
various vendors use. He does free consulting and knows a _lot_ of people
in the Bluetooth world. He is likely to know about other Bluetooth
efforts for Linux.

I can also help out with concepts/overviews etc. I have designed RFICs
for Bluetooth and am part of the SIG writing version 1.2 of the standard
(and no, I didn't do any of version 1.1 so don't hassle me!).

Duncan

On 04-Oct-01 Maksim Yevmenkin wrote:
>
>> Is anyone working on bluetooth drivers and accompanying userland programs
>> (bluetooth equivalents of wicontrol, etc.) ?
>
> ok :) i'm actually working on BlueTooth stack for FreeBSD. so far
> i have some code that implements basic functionality for HCI layer.
> the implementation is based on Netgraph and supposed to be completely
> optional.
>
> thanks,
> max
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>

- ---
________________________________________________________________________
Duncan Barclay | God smiles upon the little children,
dm...@dmlb.org | the alcoholics, and the permanently stoned.
dm...@freebsd.org| Steven King

------------------------------

Date: Thu, 4 Oct 2001 07:51:58 -0700 (PDT)
From: John Kozubik <jo...@kozubik.com>
Subject: Re: bluetooth

I found my cards at pricewatch.com - just type bluetooth into the top
search textbox - you should see 3com and xircom cards come up for $120 -
$150.

- -----
John Kozubik - jo...@kozubik.com - http://www.kozubik.com

On Thu, 4 Oct 2001, Nicolai Petri wrote:

> Hi Warner,
>
> I've seen cards for sale on http://www.digianswer.dk (Motorola's Bluetooth
> center), the price is 200$ for a retail pccard.
>
> Best regards,
> - Nicolai Petri
>
> ----- Original Message -----
> From: "Warner Losh" <i...@harmony.village.org>
> To: "John Kozubik" <jo...@kozubik.com>
> Cc: <freebsd...@FreeBSD.ORG>
> Sent: Thursday, October 04, 2001 3:08 AM
> Subject: Re: bluetooth
>
>
> > In message <Pine.BSF.4.21.011003...@www.kozubik.com> John
> Kozubik writes:
> > : Is anyone working on bluetooth drivers and accompanying userland
> programs
> > : (bluetooth equivalents of wicontrol, etc.) ?
> >
> > I tried to get a bluetooth pcmcia card, but I haven't been able to win
> > one on ebay or find one availble through more normal channels.
> >
> > I've also had no luck finding datasheets on the bluetooth stuff, but
> > to be honest I haven't tried too hard.
> >
> > Warner
> >
> > To Unsubscribe: send mail to majo...@FreeBSD.org
> > with "unsubscribe freebsd-hackers" in the body of the message
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>

------------------------------

Date: Thu, 04 Oct 2001 08:53:58 -0700
From: Maksim Yevmenkin <myev...@digisle.net>
Subject: Re: bluetooth

Duncan

> I might be worth talking to the people at
>
> http://www.blueaid.com/

Thanks for the info!

> Bill Munday has written and architected a number of the Bluetooth stacks
> various vendors use. He does free consulting and knows a _lot_ of people
> in the Bluetooth world. He is likely to know about other Bluetooth
> efforts for Linux.

Again thanks for the name :) As far as Linux concern, i'm aware of two
BlueTooth stacks for Linux

1) AXIS OpenBT stack (http://sourceforge.net/projects/openbt/)
2) Bluez (http://bluez.sourceforge.net/)
(i actually know the Bluez author. Great programmer, we use
to work together.)

> I can also help out with concepts/overviews etc. I have designed RFICs
> for Bluetooth and am part of the SIG writing version 1.2 of the standard
> (and no, I didn't do any of version 1.1 so don't hassle me!).

Well, i would like to take this opportunity and tell a little bit more
about current status :) If anyone feels that it is not appropriate place
or time please let me know.

[...]

> > the implementation is based on Netgraph and supposed to be completely
> > optional.

The current design goals are:

1) Minimal changes to FreeBSD kernel code. It should be possible
to maintain stack outside of FreeBSD code if required.
2) Stack must be optional. Do not want it - do not use it.
3) Stack must be flexible. Parts of the stack must be replaceable.
4) Stack must provide access to all protocol layers.
5) Try to avoid (if possible) kernel threads and try to
reduce or eliminate extra overhead on synchronization.
6) Stack must provide option to configure each unit in "special"
way to work around possible hardware bugs.
7) Try to stay within Netgraph infrastructure and reuse most
of Netgraph tools (ngctl etc).

i want to do something different rather than "classic" network
stack. That is why i decided to try Netgraph framework. It is
highly experimental code (proof of concept, if you will :)

So far things looks like this. Please note i'm still working
on this and there might be other "oop"es and "gotcha"s :)

x x
| | User space
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
| | Kernel /
| sco | acl \
+--V-----------------V--+ /
| | cmd \
| Netgraph HCI node <---------------/--> "btd"
| | \ daemon.
+----------^------------+ / Controls BlueTooth
| drv \ unit
|
|
| right Kernel space / User space
+----------V------------+ \
| |---------------/-->
| Netgraph "tee" node | righ2left \ "btdump"
| |---------------/--> utility
+----------^------------+ left2right \ Dumps all packets
| left / "a-la" tcpdump
|
|
| hook
+----------V------------+
| |
| BlueTooth unit driver |
| (Netgraph node) |
| |
+-----------------------+

New instance of a HCI node are created for each BlueTooth unit.
The participating nodes are connected as described above. The
HCI node exports three hooks:

1) acl - ACL data (Data)
2) sco - SCO data (Voice)
3) cmd - special hook that allows to send HCI commands to the unit.

All HCI commands and events are mapped to Netgraph control
messages. One HCI command/event - one control message. The "tee"
node is used to provide access to raw data and if this is not
required may be omitted.

The current model is one user space process per BlueTooth unit.
However it might be converted to thread per process model.
Control daemon "btd" is responsible for initialization and
control of the unit. When daemon starts it sends set of HCI
commands to recognize unit and then sends another set of HCI
commands to perform actual intialization. Results are reported
back in form of Netgraph control messages. The initialization
sequence may vary depending on specific unit (to work around
possible hardware bugs) and daemon must decide if it was
successful or not.

The control daemon also may implement additional features
such as management of pin codes and link keys etc.

In the near future there will be L2CAP node that will be
attached to "acl" hook. But for now it is possible to
implement L2CAP procotol as user space daemon, and then
convert it to Netgraph node. The same is true for RFCOMM,
SDP and TCP (Telephony Control Protocol :) nodes.

thanks,
max

------------------------------

Date: Thu, 4 Oct 2001 18:03:56 +0200
From: Guido van Rooij <gu...@gvr.org>
Subject: grep memory footage

When fgrepping a huge file (say 10GB) for a non-existing string,
fgrep's memory size skyrockets. At a certain point in time its SIZE was 391M
(RSS was about 30MB) and the system got rather unreponsive. The
string was about 12 bytes big, and we fail to see why grep would
need so much.

Is there a good explanation for this?

- -Guido

------------------------------

Date: Thu, 04 Oct 2001 09:07:19 -0700
From: Farooq Mela <fme...@sm.socccd.cc.ca.us>
Subject: Re: current strstr(3) implementation is slow

"Andrew L. Neporada" wrote:
> to Algorithms" book (AKA CLR) by MIT Press, more precisely "Knuth, Morris
> and Pratt algorithm".

Hmm, sounds good, much better than naive string matching algorithm.
However I think it would be a good idea to check if the length of the
pattern <= architecture's word size (i386 is 32, alpha is 64, etc),
and if so use shift-or matching [Baeza-Yates & Gonnet, "A New Approach
to Text Searching," CACM 35, Oct. 1992, 74-82]. Shift-or matching only
requires an array of 256 * word size bits which can be on the stack,
but KMP matching needs O(M) which must be malloc'ed. Shift-or is
usually considerably faster than KMP algorithm, see paper for details.

- --
farooq <fme...@sm.socccd.cc.ca.us>

------------------------------

Date: Thu, 4 Oct 2001 20:40:24 +0000
From: Vladimir Dozen <vladimi...@mail.ru>
Subject: Re: VM: file swapping (this time in libc): patch

ehlo.

I was told that diff format I used is unappropriate for most cases,
so I redo it in unified (-u) format.

Purpose: to allow developers of large applications to use system
memory allocation routines for allocating in mmap()ed file
instead of writing own ones. Also, allow to run applications that
may use huge amount of memory (like Gimp) without reconfiguring
swap.

Patch description: the patch implements file-backed memory
allocation for regular malloc() routine. If 'F' flag is set
in malloc options, instead of doing mmap(MAP_ANON), malloc()
maps regions from temporal file. File is growed as neccessary,
and new regions are mapped from the same file.

Details: to avoid using two methods of allocation (brk() and mmap()) in
the same file, regular allocation altered to use mmap(). This
is done by writing emulators (brk_emulator() and sbrk_emulator()).
File allocator uses single descriptor (usually fd==512). File is
created in directory specified by $SWAPDIR, $TMPDIR or "/tmp"
(in this order). $SWAPDIR is introduced since often people use
memory file system for /tmp. Temporal file is unlinked after
creation, so it will be deleted automatically at exit.

Informal testing shows no performance hit comparing with old-style
brk() allocation, and small hit when using file-backed allocation.

Here the patch (made on 4.3-RELEASE-p20)
===============================
- --- malloc.c.old Tue Oct 2 12:52:25 2001
+++ malloc.c Thu Oct 4 20:05:52 2001
@@ -97,7 +97,7 @@
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
- -
+
/*
* This structure describes a page worth of chunks.
*/
@@ -245,9 +245,6 @@
#define UTRACE(a,b,c)
#endif /* HAS_UTRACE */

- -/* my last break. */
- -static void *malloc_brk;
- -
/* one location cache for free-list holders */
static struct pgfree *px;

@@ -262,6 +259,7 @@
mmap(0, (size), PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, \
MMAP_FD, 0);

+
/*
* Necessary function declarations
*/
@@ -297,6 +295,167 @@
}

/*
+ * file swap options
+ */
+static int malloc_file_swap;
+static char* malloc_file_swap_dir;
+static int malloc_file_swap_num;
+static int malloc_file_swap_fd;
+static int malloc_file_swap_offset;
+static int malloc_file_swap_size;
+
+/*
+ * mmap-based brk/sbrk emulation
+ */
+static char *malloc_brk;
+static char* sbrk_emulation(int incr)
+{
+ if( incr == 0 ) return malloc_brk;
+ wrterror("unsupported sbrk argument");
+};
+
+/**
+ * brk emulation
+ *
+ * note that return value is different from brk!
+ * @result 0 allocation failed, ptr -- start of new block
+ * @param new_brk desired location of new top of heap
+ *
+ */
+static char* brk_emulation(char* new_brk)
+{
+ char* p;
+ char buf[4096];
+ int filegrow,wr,blocksize;
+ int stage;
+ int tmp_fd;
+
+ /* size of requested block */
+ blocksize = new_brk-malloc_brk;
+
+ /* increase heap size */
+ if( blocksize > 0 )
+ {
+ if( malloc_file_swap )
+ {
+ /* create file at first call */
+ if( malloc_file_swap_num == 0 )
+ {
+ /* where to put swap file */
+ if( !malloc_file_swap_dir ) malloc_file_swap_dir = getenv("SWAPDIR");
+ if( !malloc_file_swap_dir ) malloc_file_swap_dir = getenv("TMPDIR");
+ if( !malloc_file_swap_dir ) malloc_file_swap_dir = "/tmp";
+
+ /* generate random file name and open it */
+ do
+ {
+ snprintf(buf,sizeof(buf),"%s/%08x.swap",
+ malloc_file_swap_dir,malloc_file_swap_num);
+ malloc_file_swap_num *= 11;
+ malloc_file_swap_num += 13;
+ malloc_file_swap_fd = open(buf,O_CREAT|O_EXCL|O_RDWR|O_NOFOLLOW,0600);
+ }
+ while( malloc_file_swap_fd < 0 && errno == EEXIST );
+ if( malloc_file_swap_fd < 0 ) return 0;
+
+ /*
+ * some shell scripts (GNU configure?) can be
+ * unhappy if we use descriptor 4 or 5; also qmail-send
+ * uses descriptors up to 6 in normal mode.
+ * so we dup descriptor into large enough and close original
+ */
+ tmp_fd = 512;
+ while( tmp_fd >= 0 && dup2(malloc_file_swap_fd,tmp_fd) < 0 ) tmp_fd--;
+ if( tmp_fd < 0 ) return 0;
+ close(malloc_file_swap_fd);
+ malloc_file_swap_fd = tmp_fd;
+
+ /* unlink file to autoremove it at last reference lost */
+ unlink(buf);
+ }
+
+ if( malloc_file_swap_offset+blocksize > malloc_file_swap_size )
+ {
+ /* fill tail of file with zeroes */
+ memset(buf,0,sizeof(buf));
+
+ /*
+ * grow file
+ * critical grow:
+ * allocate requested size; if any error happens here,
+ * whole allocation fails;
+ * supplemental grow:
+ * pre-allocate one more megabyte; errors are ignored
+ */
+ for( stage=0; stage<2; stage++ )
+ {
+ if( stage == 0 ) filegrow = blocksize;
+ else filegrow = 1024*1024;
+
+ while( filegrow > 0 )
+ {
+ /* note that file position is always at end of file */
+ wr = write(malloc_file_swap_fd,
+ buf,sizeof(buf)<filegrow?sizeof(buf):filegrow);
+ if( wr < 0 )
+ {
+ if( errno == EINTR ) continue;
+ if( stage == 0 ) return 0;
+ break;
+ }
+ filegrow -= wr;
+
+ /* keep file size for next time */
+ malloc_file_swap_size += wr;
+ }
+ }
+ }
+
+ /* map file tail into address space */
+ p = mmap(malloc_brk,blocksize,
+ PROT_READ|PROT_WRITE,
+ MAP_SHARED|MAP_NOSYNC|MAP_INHERIT,
+ malloc_file_swap_fd,
+ malloc_file_swap_offset);
+ if( p == MAP_FAILED ) return 0;
+
+ /* shift offset to use it next time in mmap */
+ malloc_file_swap_offset += blocksize;
+ }
+ else
+ {
+ /* FIXME: we might use file swap if regular swapping failed;
+ * but this may only happen when limit reached; can
+ * we break limits with mmap()? */
+ p = mmap(malloc_brk,new_brk-malloc_brk,
+ PROT_READ|PROT_WRITE,
+ MAP_ANON|MAP_PRIVATE,MMAP_FD,0);
+ if( p == MAP_FAILED ) return 0;
+ }
+
+ malloc_brk = p+blocksize;
+ return p;
+ }
+ else
+ {
+ /* here we must unmap memory */
+ if( malloc_file_swap )
+ {
+ /* for file-backed allocation just shift offset back */
+ malloc_file_swap_offset -= blocksize;
+ return malloc_brk;
+ }
+ else
+ {
+ /* i'm not sure if unmap is good idea, but ... */
+ munmap(new_brk,blocksize);
+ malloc_brk = new_brk;
+ return malloc_brk;
+ }
+ }
+}
+
+/*
* Allocate a number of pages from the OS
*/
static void *
@@ -304,21 +463,20 @@
{
caddr_t result, tail;

- - result = (caddr_t)pageround((u_long)sbrk(0));
+ result = (caddr_t)pageround((u_long)sbrk_emulation(0));
tail = result + (pages << malloc_pageshift);

- - if (brk(tail)) {
+ result = brk_emulation(tail);
+ if( result == 0 ) {
#ifdef EXTRA_SANITY
wrterror("(ES): map_pages fails\n");
#endif /* EXTRA_SANITY */
return 0;
}
+ tail = result + (pages << malloc_pageshift);

last_index = ptr2index(tail) - 1;
- - malloc_brk = tail;
- -
- - if ((last_index+1) >= malloc_ninfo && !extend_pgdir(last_index))
- - return 0;;
+ if ((last_index+1) >= malloc_ninfo && !extend_pgdir(last_index)) return 0;;

return result;
}
@@ -428,6 +586,8 @@
case 'X': malloc_xmalloc = 1; break;
case 'z': malloc_zero = 0; break;
case 'Z': malloc_zero = 1; break;
+ case 'f': malloc_file_swap = 0; break;
+ case 'F': malloc_file_swap = 1; break;
default:
j = malloc_abort;
malloc_abort = 0;
@@ -464,7 +624,7 @@
* We need a maximum of malloc_pageshift buckets, steal these from the
* front of the page_directory;
*/
- - malloc_origo = ((u_long)pageround((u_long)sbrk(0))) >> malloc_pageshift;
+ malloc_origo = ((u_long)pageround((u_long)sbrk_emulation(0))) >> malloc_pageshift;
malloc_origo -= malloc_pageshift;

malloc_ninfo = malloc_pagesize / sizeof *page_dir;
@@ -478,7 +638,7 @@

/*
* This is a nice hack from Kaleb Keithly (ka...@x.org).
- - * We can sbrk(2) further back when we keep this on a low address.
+ * We can sbrk_emulation(2) further back when we keep this on a low address.
*/
px = (struct pgfree *) imalloc (sizeof *px);

@@ -513,7 +673,7 @@
wrterror("(ES): zero entry on free_list\n");
if (pf->page > pf->end)
wrterror("(ES): sick entry on free_list\n");
- - if ((void*)pf->page >= (void*)sbrk(0))
+ if ((void*)pf->page >= (void*)sbrk_emulation(0))
wrterror("(ES): entry on free_list past brk\n");
if (page_dir[ptr2index(pf->page)] != MALLOC_FREE)
wrterror("(ES): non-free first page on free-list\n");
@@ -544,11 +704,9 @@
wrterror("(ES): allocated non-free page on free-list\n");
#endif /* EXTRA_SANITY */

- - size >>= malloc_pageshift;
- -
/* Map new pages */
- - if (!p)
- - p = map_pages(size);
+ size >>= malloc_pageshift;
+ if (!p) p = map_pages(size);

if (p) {

@@ -920,7 +1078,7 @@
if (!pf->next && /* If we're the last one, */
pf->size > malloc_cache && /* ..and the cache is full, */
pf->end == malloc_brk && /* ..and none behind us, */
- - malloc_brk == sbrk(0)) { /* ..and it's OK to do... */
+ malloc_brk == sbrk_emulation(0)) { /* ..and it's OK to do... */

/*
* Keep the cache intact. Notice that the '>' above guarantees that
@@ -929,8 +1087,8 @@
pf->end = (char *)pf->page + malloc_cache;
pf->size = malloc_cache;

- - brk(pf->end);
- - malloc_brk = pf->end;
+ /* FIXME: here we must check returned address */
+ brk_emulation(pf->end);

index = ptr2index(pf->end);
last_index = index - 1;
===============================

- --
dozen @ home

------------------------------

Date: Thu, 4 Oct 2001 18:43:29 +0200 (CEST)
From: Heiko Schaefer <hsch...@fto.de>
Subject: RE: [xine-user] xine on freebsd?

Hey everyone,

> > Also, are you sure that you have enough shared memory on the freebsd box?
> By
> > default the amount of shm you can use is fairly small, and if you use
> GNOME it
> > will easily eat it all.
>
> I can't agree with this statement more. Gnome/GTK is a pig on SHM, and the
> FreeBSD default make relatively low amounts of memory and segments
> available. There are various kernel options and tunables that can be set to
> ajust this.

is there anything expect for

kern.ipc.shmmax=67108864
kern.ipc.shmall=32768

that is worth looking into !?

xine's documentation says to set these values already for a very long
time, as without such a setting xine won't run at all.

Heiko

------------------------------

Date: Thu, 4 Oct 2001 13:28:30 EDT
From: Bsd...@aol.com
Subject: 64bit Ethernet Card (if_sf driver)

I've been testing the adaptec 64044 card (if_sf driver) which is a 64bit
66Mhz 4 port ethernet. I can have come to one of two conclusions:

1) the card sucks
2) the driver sucks

or both. A 32bit Dlink 4 port card outperforms it by a wide margin, as do
32bit eepro100s. "wide margin" being defined as about 40%.

Given that bus resources are not easily measureable..Im quoting cpu usage for
handling the same number of pps. But its pretty difficult to justify using a
64bit slot and rather expensive card with such lousy performance. I cant even
justify the bus-bandwidth saving with a card that cant route more than
250Mb/s.

I guess my question has to do with whether the board is just a dog or the
driver needs substantial optimization. The folks at adaptec aren't dopes
generally, so I cant imagine that they chose a chipset that was so inferior
to the one on their 32bit adapter (which uses the same as the Dlink).

Anyone with experience or ideas?

Bryan

------------------------------

Date: 04 Oct 2001 19:42:57 +0200
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: if_sf bug

Doug White <dwh...@resnet.uoregon.edu> writes:
> On Wed, 3 Oct 2001 Bsd...@aol.com wrote:
> > The if_sf driver doesnt seem to initialize itself until an address is set,
> > which makes things like tcpdump, bridging and other promiscuous things not
> > work.
> All the interfaces do that. If you want to make an invisible interface,
> configure it with IP 0.0.0.0.

I believe 'ifconfig foo0 up' is sufficient.

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: 04 Oct 2001 19:52:36 +0200
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: ALT-<sp> (Was: how to make 'for' understand two words as a singleargumen)

Michael Sinz <ms...@wgate.com> writes:
> BTW - How does your system represent a file with 0xA0 in it? An ls on
> FreeBSD 4.4-Stable seems to show it as:
>
> -rw-r--r-- 1 msinz msinz 0 Oct 3 12:00 foo?bar
>
> Interesting - not what I would have expected but I think "non-printables"
> are replaced by the "?" when ls runs.
>
> Even more interesting is this:
>
> -rw-r--r-- 1 msinz msinz 0 Oct 3 12:00 foo?bar
> -rw-r--r-- 1 msinz msinz 1 Oct 3 12:05 foo?bar
>
> (one has a linefeed in the name and one has a non-breaking space in the name)

This is only "interesting" (in the sense in which you seem to use the
word) to someone who has not read the ls(1) manual page, and does not
know of the -q and -B options...

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: 04 Oct 2001 19:59:30 +0200
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: Make a kernel in a different directory

Zhihui Zhang <zzh...@cs.binghamton.edu> writes:
> I put the whole kernel code under /test by the following command:
> [...]
> I go to the directory and there is nothing except Makefile there:

The object files and the compiled module are located in
/test/sys/compile/TRY/modules/test/sys/modules/accf_http (unless
you've done something funky with symlinks).

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: Thu, 4 Oct 2001 14:23:51 -0400 (EDT)
From: Zhihui Zhang <zzh...@cs.binghamton.edu>
Subject: Re: Make a kernel in a different directory

Thanks for your reply. I check the directories. You are right. Normally,
it is under
/usr/src/sys/compile/TFS/modules/usr/src/sys/modules/accf_http.

Do I have to set up some symbolic links or modify some environment
variable to make "make install" work in my case (find the KLDs under
TRY/modules/test/... not under the normal patch)?

- -Zhihui

On 4 Oct 2001, Dag-Erling Smorgrav wrote:

> Zhihui Zhang <zzh...@cs.binghamton.edu> writes:
> > I put the whole kernel code under /test by the following command:
> > [...]
> > I go to the directory and there is nothing except Makefile there:
>
> The object files and the compiled module are located in
> /test/sys/compile/TRY/modules/test/sys/modules/accf_http (unless
> you've done something funky with symlinks).
>
> DES
> --
> Dag-Erling Smorgrav - d...@ofug.org
>

------------------------------

Date: Thu, 04 Oct 2001 11:30:43 -0700
From: "Bruce A. Mah" <bm...@FreeBSD.ORG>
Subject: Re: if_sf bug

- --==_Exmh_1798317949P
Content-Type: text/plain; charset=us-ascii

If memory serves me right, Dag-Erling Smorgrav wrote:
> Doug White <dwh...@resnet.uoregon.edu> writes:
> > On Wed, 3 Oct 2001 Bsd...@aol.com wrote:
> > > The if_sf driver doesnt seem to initialize itself until an address is set
> ,
> > > which makes things like tcpdump, bridging and other promiscuous things no
> t
> > > work.
> > All the interfaces do that. If you want to make an invisible interface,
> > configure it with IP 0.0.0.0.
>
> I believe 'ifconfig foo0 up' is sufficient.

Confirming data point: "ifconfig dc0 up" allowed tcpdump in promiscuous
mode when I tried it.

Bruce.

- --==_Exmh_1798317949P
Content-Type: application/pgp-signature

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: Exmh version 2.3.1+ 05/14/2001

iD8DBQE7vKrS2MoxcVugUsMRAjx+AKCKGXJ2DGa+buTBcH+Yye9A9OYvwwCfVjSH
U7qNncTSMURUWENjvLHANIM=
=xQ6c
- -----END PGP SIGNATURE-----

- --==_Exmh_1798317949P--

------------------------------

Date: Thu, 04 Oct 2001 11:49:49 -0700
From: Mike Smith <msm...@freebsd.org>
Subject: Re: grep memory footage

>
> When fgrepping a huge file (say 10GB) for a non-existing string,
> fgrep's memory size skyrockets. At a certain point in time its SIZE was 391M
> (RSS was about 30MB) and the system got rather unreponsive. The
> string was about 12 bytes big, and we fail to see why grep would
> need so much.
>
> Is there a good explanation for this?

It's a known bug in grep; there are probably a bunch of PRs outstanding
on it. We need grep to be updated.

- --
... 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

------------------------------

Date: Thu, 4 Oct 2001 22:02:20 +0300
From: Ruslan Ermilov <r...@FreeBSD.ORG>
Subject: Re: grep memory footage

On Thu, Oct 04, 2001 at 11:49:49AM -0700, Mike Smith wrote:
> >
> > When fgrepping a huge file (say 10GB) for a non-existing string,
> > fgrep's memory size skyrockets. At a certain point in time its SIZE was 391M
> > (RSS was about 30MB) and the system got rather unreponsive. The
> > string was about 12 bytes big, and we fail to see why grep would
> > need so much.
> >
> > Is there a good explanation for this?
>
> It's a known bug in grep; there are probably a bunch of PRs outstanding
> on it. We need grep to be updated.
>
The sad thing is that GNU Grep has recently lost his maintainer.
Let me know if you want additional details.

Cheers,
- --
Ruslan Ermilov Oracle Developer/DBA,
r...@sunbay.com Sunbay Software AG,
r...@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine

http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age

------------------------------

Date: Thu, 4 Oct 2001 13:06:44 -0600
From: "DOROVSKOY,IGOR (A-Portsmouth,ex1)" <igor_do...@agilent.com>
Subject: GA621 ?

Is anyone got running Netgear gigabit nic GA621 in 4.4?

cheers,
Igor

------------------------------

Date: Thu, 04 Oct 2001 15:39:48 -0400
From: Michael Sinz <ms...@wgate.com>
Subject: Re: ALT-<sp> (Was: how to make 'for' understand two words as asingleargumen)

Dag-Erling Smorgrav wrote:
>
> Michael Sinz <ms...@wgate.com> writes:
> > BTW - How does your system represent a file with 0xA0 in it? An ls on
> > FreeBSD 4.4-Stable seems to show it as:
> >
> > -rw-r--r-- 1 msinz msinz 0 Oct 3 12:00 foo?bar
> >
> > Interesting - not what I would have expected but I think "non-printables"
> > are replaced by the "?" when ls runs.
> >
> > Even more interesting is this:
> >
> > -rw-r--r-- 1 msinz msinz 0 Oct 3 12:00 foo?bar
> > -rw-r--r-- 1 msinz msinz 1 Oct 3 12:05 foo?bar
> >
>
> This is only "interesting" (in the sense in which you seem to use the
> word) to someone who has not read the ls(1) manual page, and does not
> know of the -q and -B options...

This was within the context of alt-space replacing spaces in file names.
As things stand now, it is not even easily usable as the main tool used
to list the files in a directory does not show it correctly. (As far as
the non-printables, I agree that LS is supposed to do, but is non-breaking
space really a non-printable?)

- --
Michael Sinz ---- Worldgate Communications ---- ms...@wgate.com
A master's secrets are only as good as
the master's ability to explain them to others.

------------------------------

End of freebsd-hackers-digest V5 #260
*************************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-hackers-digest in the body of the message