Re: question about boot loaders

[Neil Blakey-Milner]

On Thu 1999-12-09 (02:46), Robert Watson wrote:
> Once we get into boot2 land, I recognize the FreeBSD-specific loading
> code, etc.  What I don't know much about is those first three 512-byte
> chunks of code.  Boot0 appears to be booteasy, but given some ignorance
> about the i386 boot process, I'm not sure whether it's loaded by mbr, or
> by the bios, and where it lives partition-wise.  Similarly, how boot1 fits
> into it the whole scheme--I assume this is FreeBSD-specific as it knows
> about boot2, but don't know where it lives, etc.  Preferably, afterwards,
> also drop the results into sys/boot/i386/README. :-)

I wrote up some basic stuff, which doesn't seem quite to describe
what you're after, but which may be of use, at
http://rucus.ru.ac.za/~nbm/boot/

It's intended for the handbook, but I haven't had time since starting
my new job to work on it much more.

Neil
-- 
Neil Blakey-Milner
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: question about boot loaders

[Robert Watson]

On Thu, 9 Dec 1999, Neil Blakey-Milner wrote:

> On Thu 1999-12-09 (02:46), Robert Watson wrote:
> > Once we get into boot2 land, I recognize the FreeBSD-specific loading
> > code, etc.  What I don't know much about is those first three 512-byte
> > chunks of code.  Boot0 appears to be booteasy, but given some ignorance
> > about the i386 boot process, I'm not sure whether it's loaded by mbr, or
> > by the bios, and where it lives partition-wise.  Similarly, how boot1 fits
> > into it the whole scheme--I assume this is FreeBSD-specific as it knows
> > about boot2, but don't know where it lives, etc.  Preferably, afterwards,
> > also drop the results into sys/boot/i386/README. :-)
> 
> I wrote up some basic stuff, which doesn't seem quite to describe
> what you're after, but which may be of use, at
> http://rucus.ru.ac.za/~nbm/boot/
> 
> It's intended for the handbook, but I haven't had time since starting
> my new job to work on it much more.

Looks interesting, but doesn't seem to mention the mbr/mbr.s code, and I'm
not sure how this fit into the picture.  There seem to be three 512-byte
chunks of code:

-r--r--r--   1 root  wheel 512 Sep 16 18:46 mbr
-r--r--r--   1 root  wheel 512 Sep 16 18:46 boot0
-r--r--r--   1 root  wheel 512 Sep 16 18:46 boot1
-r--r--r--   1 root  wheel7680 Sep 16 18:46 boot2
-r-xr-xr-x   1 root  wheel  131072 Sep 16 18:46 loader*

When there were two of them, I understood pretty much what was going on.
Now there are three, and I clearly haven't been keeping a close enough eye
on what is going on, because now I'm confused whereas previously I wasn't
:-).  

  Robert N M Watson 

[EMAIL PROTECTED]  http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Possible libc changes to support LinuxThreads

[Jason Evans]

I've got a port of the most recent LinuxThreads (glibc-linuxthreads-2.1.2)
running, but ran into a couple of minor problems integrating with our libc.
LinuxThreads redefines a number of functions in order to make them either
support thread cancellation or work correctly.

The following functions need an alternative name, just as, for example,
write() is actually _write():

lseek()
pause()
system()
tcdrain()
wait()
waitpid()
recv()
send()

This would allow implementing cancellation points for these functions.  All
in all, I won't lose much sleep over this, but if it's easy to do and
doesn't violate some rule of symbol naming, it would be nice.

The other issue has to do with longjmp() and siglongjmp(), and is of a
similar nature, except that _longjmp() already exists as a separate
interface.  So, at least in the case of longjmp(), it needs to have a
different alias, perhaps __longjmp().  Below is a *very* simplistic patch
to libc that works, but it may make some people's skin crawl.  Feedback is
welcome.  If there is no correct way to create aliases to function entry
points, then we can do without them, but it will mean that the *jmp()
functions cannot be used in conjunction with thread cleanup handlers when
using LinuxThreads.

Jason

Index: i386/gen/setjmp.S
===
RCS file: /home/ncvs/src/lib/libc/i386/gen/setjmp.S,v
retrieving revision 1.11
diff -u -r1.11 setjmp.S
--- setjmp.S1999/10/10 08:38:33 1.11
+++ setjmp.S1999/12/09 02:07:45
@@ -54,6 +54,7 @@
 #include "DEFS.h"
 #include "SYS.h"
 
+ENTRY(__setjmp)
 ENTRY(setjmp)
movl4(%esp),%ecx
PIC_PROLOGUE
@@ -80,6 +81,7 @@
xorl%eax,%eax
ret
 
+ENTRY(__longjmp)
 ENTRY(longjmp)
movl4(%esp),%edx
PIC_PROLOGUE
Index: i386/gen/sigsetjmp.S
===
RCS file: /home/ncvs/src/lib/libc/i386/gen/sigsetjmp.S,v
retrieving revision 1.13
diff -u -r1.13 sigsetjmp.S
--- sigsetjmp.S 1999/09/29 15:18:35 1.13
+++ sigsetjmp.S 1999/12/09 02:07:45
@@ -59,6 +59,7 @@
  * use sigreturn() if sigreturn() works.
  */
 
+ENTRY(__sigsetjmp)
 ENTRY(sigsetjmp)
movl8(%esp),%eax
movl4(%esp),%ecx
@@ -89,6 +90,7 @@
xorl%eax,%eax
ret
 
+ENTRY(__siglongjmp)
 ENTRY(siglongjmp)
movl4(%esp),%edx
cmpl$0,44(%edx)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: question about boot loaders

[Robert Watson]

dcs suggests that the correct answer is:

mbr is a replacement for boot0, without the OS choices.  This seems to
make sense, so I'll go with that unless someone has a better idea :-).  We
assume that you would never, therefore, use both mbr and boot0, explaining
why there doesn't need to be an extra 512 bytes somewhere :-).

Thanks,

On Thu, 9 Dec 1999, Neil Blakey-Milner wrote:

> On Thu 1999-12-09 (02:46), Robert Watson wrote:
> > Once we get into boot2 land, I recognize the FreeBSD-specific loading
> > code, etc.  What I don't know much about is those first three 512-byte
> > chunks of code.  Boot0 appears to be booteasy, but given some ignorance
> > about the i386 boot process, I'm not sure whether it's loaded by mbr, or
> > by the bios, and where it lives partition-wise.  Similarly, how boot1 fits
> > into it the whole scheme--I assume this is FreeBSD-specific as it knows
> > about boot2, but don't know where it lives, etc.  Preferably, afterwards,
> > also drop the results into sys/boot/i386/README. :-)
> 
> I wrote up some basic stuff, which doesn't seem quite to describe
> what you're after, but which may be of use, at
> http://rucus.ru.ac.za/~nbm/boot/
> 
> It's intended for the handbook, but I haven't had time since starting
> my new job to work on it much more.
> 
> Neil
> -- 
> Neil Blakey-Milner
> [EMAIL PROTECTED]
> 


  Robert N M Watson 

[EMAIL PROTECTED]  http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Possible libc changes to support LinuxThreads

[Peter Wemm]

Jason Evans wrote:
> I've got a port of the most recent LinuxThreads (glibc-linuxthreads-2.1.2)
> running, but ran into a couple of minor problems integrating with our libc.
> LinuxThreads redefines a number of functions in order to make them either
> support thread cancellation or work correctly.
> 
> The following functions need an alternative name, just as, for example,
> write() is actually _write():
> 
> lseek()
> pause()
> system()
> tcdrain()
> wait()
> waitpid()
> recv()
> send()
> 
> This would allow implementing cancellation points for these functions.  All
> in all, I won't lose much sleep over this, but if it's easy to do and
> doesn't violate some rule of symbol naming, it would be nice.

You know about weak symbol redirection, right?  It basically allows runtime
resolution of symbols instead of link time.  So, you could have a weak
pointer from lseek to _lseek and provide a _lseek function in libc.  When
programs link against "lseek" (including within libc itself), they hold a
pointer to the non-redirected name.  If you *also* provide a "lseek" in
libpthreads from linuxthreads, then at runtime everything (including libc) will
use the lseek() in the thread library and not _lseek().

Look for __weak_reference() etc, there are some examples in libc/net/* (but
those are for different problems).

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

firewall problem?

[Ralph Utbult]

Hi

I´m sitting behind a firewall consisting av FreeBsd and Squid. My mail program is 
Popper. I can mail to (and from) every adress I´ve tried - except freebsd.org. Here´s 
the error.
The original message was received at Wed, 8 Dec 1999 16:40:08 +0100 (CET)
from [192.168.1.2]


   - The following addresses had transient non-fatal errors -
<[EMAIL PROTECTED]>


   - Transcript of session follows -
.. while talking to hub.freebsd.org.:
>>> RCPT To:<[EMAIL PROTECTED]>
<<< 450 Client host rejected: cannot find your hostname, [62.20.54.54]
<[EMAIL PROTECTED]>... Deferred: 450 Client host rejected: cannot find your 
hostname, [62.20.54.54]
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old
Reporting-MTA: dns; hyndan.gbg.abf.se
Arrival-Date: Wed, 8 Dec 1999 16:40:08 +0100 (CET)


Final-Recipient: RFC822; [EMAIL PROTECTED]
Action: delayed
Status: 4.2.0
Remote-MTA: DNS; hub.freebsd.org
Diagnostic-Code: SMTP; 450 Client host rejected: cannot find your hostname, 
[62.20.54.54]
Last-Attempt-Date: Wed, 8 Dec 1999 20:52:11 +0100 (CET)
Will-Retry-Until: Mon, 13 Dec 1999 16:40:08 +0100 (CET)
Return-Path: <[EMAIL PROTECTED]>
Received: from ralph ([192.168.1.2])
by hyndan.gbg.abf.se (8.9.3/8.9.3) with ESMTP id QAA63400;
Wed, 8 Dec 1999 16:40:08 +0100 (CET)
Message-Id: <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Wed, 08 Dec 1999 17:45:52 +0100
To: [EMAIL PROTECTED]
From: Ralph Utbult <[EMAIL PROTECTED]>
Subject: Test - ignore!
Cc: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed

What is the problem?

Regards,
Ralph Utbult
Systems Operator
ABF Göteborg
Sweden

Gratis epost med TJOHOOMAIL
http://www.tjohoo.se




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: firewall problem?

[Richard Smith]

Ralph Utbult wrote:
> 
> Hi
> 
> I´m sitting behind a firewall consisting av FreeBsd and Squid. My mail program is 
>Popper. I can mail to (and from) every adress I´ve tried - except freebsd.org. Here´s 
>the error.
> The original message was received at Wed, 8 Dec 1999 16:40:08 +0100 (CET)
> from [192.168.1.2]
> 
>- The following addresses had transient non-fatal errors -
> <[EMAIL PROTECTED]>
> 
>- Transcript of session follows -
> .. while talking to hub.freebsd.org.:
> >>> RCPT To:<[EMAIL PROTECTED]>
> <<< 450 Client host rejected: cannot find your hostname, [62.20.54.54]
> <[EMAIL PROTECTED]>... Deferred: 450 Client host rejected: cannot find 
>your hostname, [62.20.54.54]
> Warning: message still undelivered after 4 hours
> Will keep trying until message is 5 days old
> Reporting-MTA: dns; hyndan.gbg.abf.se
[snip]

No, name server problem.

`hyndan.gbg.abf.se' resolves to `62.20.54.54'.
But `62.20.54.54' resolves to `Non-existent host/domain'

Check your name server's PTR records.

Richard.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Possible libc changes to support LinuxThreads

[Richard Seaman, Jr.]

On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote:
> I've got a port of the most recent LinuxThreads (glibc-linuxthreads-2.1.2)
> running,

Great!

> but ran into a couple of minor problems integrating with our libc.
> LinuxThreads redefines a number of functions in order to make them either
> support thread cancellation or work correctly.
> 
> The following functions need an alternative name, just as, for example,
> write() is actually _write():
> 
> lseek()
> pause()
> system()
> tcdrain()
> wait()
> waitpid()
> recv()
> send()
> 
> This would allow implementing cancellation points for these functions.  All
> in all, I won't lose much sleep over this, but if it's easy to do and
> doesn't violate some rule of symbol naming, it would be nice.

It's my impression that glibc uses a three (four?) tiered naming
convention.  The "pure" syscall (in our case, eg. _write()).  Then
there is the version used internally in glibc (eg. _libc_write().
And finally, the version exported from glibc (eg. write()).

The merit to the three tiered system is that you might need to rewrite
the version used internally to libc for threads, but still have this
be different from the version exported from the library (eg. to
implement cancallation points without propagating them throughout
libc).

In this case, you'd want, for example, an _lseek(), _libc_lseek(),
and _seek().  

The problem with cancellation points, libc and linuxthreads has been
that you need to wade through libc and replace instances of, for 
example, write() with either _write() or _libc_write() in order to
avoid propagating cancellation points where they don't belong.

> The other issue has to do with longjmp() and siglongjmp(), and is of a
> similar nature, except that _longjmp() already exists as a separate
> interface.  So, at least in the case of longjmp(), it needs to have a
> different alias, perhaps __longjmp().  Below is a *very* simplistic patch
> to libc that works, but it may make some people's skin crawl.  Feedback is
> welcome.  If there is no correct way to create aliases to function entry
> points, then we can do without them, but it will mean that the *jmp()
> functions cannot be used in conjunction with thread cleanup handlers when
> using LinuxThreads.

__longjmp() and __siglongjmp() don't bother me at all.

-- 
Richard Seaman, Jr.   email: [EMAIL PROTECTED]
5182 N. Maple Lanephone: 262-367-5450
Chenequa WI 53058 fax:   262-367-5852


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Weird output from vmstat -m?

[Robert Withrow]

The recent discussion about route table leaks led me to check some
of my systems.  On one of them I got this:

bash-2.03$ uname -srm
FreeBSD 3.2-RELEASE i386
bash-2.03$ uptime
 7:45AM  up 28 days, 12:38, 3 users, load averages: 0.61, 0.50, 0.43
bash-2.03$ vmstat -m | grep routetbl | grep K
 routetbl60 8K 15K 40960K 18700 0  16,32,64,128,256
 routetbl60 8K 15K 40960K 18700 0  16,32,64,128,256
 routetbl60 8K 15K 40960K 18700 0  16,32,64,128,256

Eh... *Three* entries?

In fact, lots of stuff is triplicated (or more):

bash-2.03$ vmstat -m | sort | less
[snip]
  kld1679K 84K 40960K   400 0  
16,32,128,512,1K,4K,8K,64K
  kld1679K 84K 40960K   400 0  
16,32,128,512,1K,4K,8K,64K
  kld1679K 84K 40960K   400 0  
16,32,128,512,1K,4K,8K,64K
  kld1679K 84K 40960K   400 0  
16,32,128,512,1K,4K,8K,64K
[etc]

And this:

bash-2.03$ vmstat -m | less
[snip]
  64  file, lockf, namecache, devbuf, temp, session, shm, pcb,
  cluster_save buffer, vnodes, ifaddr, routetbl, NFS req, NFS daemon,
  file, lockf, namecache, devbuf, temp, session, shm, pcb,
  cluster_save buffer, vnodes, ifaddr, routetbl, NFS req, NFS daemon,
  file, lockf, namecache, devbuf, temp, session, shm, pcb,
  cluster_save buffer, vnodes, ifaddr, routetbl, NFS req, NFS daemon,
  file

This doesn't look healthy to me.  I didn't see anything about this in the
archives...

-- 
Robert Withrow -- (+1 978 288 8256)
[EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Sequence of Events in Kernel source?

[Etienne De Bruin]

Greetings Seniors.

I am interested in establishing the sequence of events from a source code
perspective from when the PC is switched on, to the login prompt.  I am
specifically interested in the setting up of lower level stuff like the drivers.
memory etc.

Can anyone please take a moment and give me some pointers?

Kind regards

eT




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: tty level buffer overflows

[Koster, K.J.]

> 
> We're seeing it with our ppp link, which uses the kernel level ppp
> code.  Since it doesn't happen for me often, it is hard to diagnose.
> 
You could set up a 486 (386?) and have it chew on a tonne of ipfw rules.
If it is due to ipfw load, you should be able to force the problem to be
reproduced by scaling down the hardware.

Kees Jan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

ifconfig panic using 3C574 card

[Stephane E. Potvin]

I just upgraded my laptop to use a fresh current from this morning
(fresh checkout with empty /usr/obj).
The machine is an IBM ThinkPad 760XD with 88Mb RAM.
Now when the ep driver attaches my 3COM 3C574 it reports the following
mac address:

ep0: <3Com 3C574> at port 0x240-0x25f irq 10 slot 0 on pccard0
ep0: Ethernet address 40:57:40:57:40:57
ep0: strange connector type in EEPROM: assuming AUI

The error is mostly harmless as the card is functionning otherwise.
(I'm not speaking about performances which are not very good right now).

Now to the subject, when I run ifconfig on the machine, I instantly got
the following panics. I guess that the second one is only an artefact of
the first one and should not be considered. dmesg, pccardc dumpcis and
config file follows. If you need anything else let me know.

I'll try to look into this as soon as I get a few minutes (well, when I
get the damn video console working on my 'winder).

Steph

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code  = supervisor read, page not present
instruction pointer = 0x8:0x0
stack pointer   = 0x10:0xc71a6de8
frame pointer   = 0x10:0xc71a6e0c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 266 (ifconfig)
interrupt mask  = net
kernel: type 12 trap, code=0
Stopped at  0:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01bc10c
stack pointer   = 0x10:0xc71a6c54
frame pointer   = 0x10:0xc71a6c58
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resule, IOPL = 0
current process = 266 (ifconfig)
interrupt mask  = net
kernel: type 12 trap, code=0

symbols near 0xc01bc10c:
c01bc0f0 T db_read_bytes
c01bc128 T db_write_bytes

dmesg output:
Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights
reserved.
FreeBSD 4.0-CURRENT #1: Thu Dec  9 08:39:31 EST 1999
[EMAIL PROTECTED]:/mnt/.0/src/sys/compile/AZIMOV
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium/P55C (165.79-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x544  Stepping = 4
  Features=0x8001bf
real memory  = 92274688 (90112K bytes)
avail memory = 86859776 (84824K bytes)
Preloaded elf kernel "kernel" at 0xc0269000.
Intel Pentium detected, installing workaround for F00F bug
npx0:  on motherboard
npx0: INT 16 interface
apm0:  on motherboard
apm: found APM BIOS v1.2, connected at v1.2
pcib0:  on motherboard
pci0:  on pcib0
isab0:  at device 1.0 on pci0
isa0:  on isab0
pcic-pci0:  at device 2.0 on pci0
pcic-pci1:  at device 2.1 on pci0
vga-pci0:  irq 11 at
device 3.0 on pci0
pci0: unknown card (vendor=0x1014, dev=0x0057) at 5.0 irq 11
atkbdc0:  at port 0x60-0x6f on isa0
atkbd0:  irq 1 on atkbdc0
psm0:  irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
ata0 at port 0x1f0 irq 14 on isa0
fdc0:  at port 0x3f0-0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
pcic: polling, can't alloc 0
pcic: polling, can't alloc 0
pcic0:  on isa0
pccard0:  on pcic0
pccard1:  on pcic0
vga0:  at port 0x3b0-0x3df iomem 0xa-0xb on
isa0
sc0:  on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
sio0 at port 0x3f8-0x3ff irq 4 on isa0
sio0: type 16550A
ppc0 at port 0x3bc-0x3c3 irq 7 on isa0
isa_compat: didn't get ports for ppc
ppc0: PC87334 chipset (ECP/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
lpt0:  on ppbus 0
lpt0: Interrupt-driven port
ad0:  ATA-3 disk at ata0 as master
ad0: 2937MB (6015744 sectors), 5968 cyls, 16 heads, 63 S/T, 512 B/S
ad0: 16 secs/int, 1 depth queue, PIO
acd0:  CDROM drive at ata0 as slave 
acd0: read 1377KB/s (1377KB/s), 256KB buffer, PIO
acd0: supported read types:
acd0: Audio: play, 256 volume levels
acd0: Mechanism: ejectable tray
acd0: Medium: CD-ROM 120mm data disc loaded, unlocked
Mounting root from ufs:/dev/ad0s1a
WARNING: / was not properly dismounted
pccard: card inserted, slot 0
ep0: <3Com 3C574> at port 0x240-0x25f irq 10 slot 0 on pccard0
ep0: Ethernet address 40:57:40:57:40:57
ep0: strange connector type in EEPROM: assuming AUI

'pccardc dumpcis' output:
Configuration data for card in slot 0
Tuple #1, code = 0x1 (Common memory descriptor), length = 2
000:  00 ff
Common memory device information:
Device number 1, type No device, WPS = OFF
Speed = No speed, Memory block size = reserved, 32 units
Tuple #2, code = 0x17 (Attribute memory descriptor), length = 3
000:  43 02 ff
Attribute memory device information:
Device number 1, type EEPROM, WPS = OFF
 

Veritas Software Now Shipping With Linux

[Charles Randall]

http://news.excite.com/news/r/991209/09/tech-veritas-linux

Veritas Software Now Shipping With Linux

MOUNTAIN VIEW, Calif. (Reuters) Veritas Software
Corp. (VRTS.O) said on Thursday its software used to backup
data on computer systems is being shipped with Red Hat
Inc.'s Linux 6.1 Delux product.

"This is the first step as a result of the agreement we
announced in early November to jointly develop enterprise
storage management solutions for the Red Hat Linux
marketplace," Paul McNamara, general manager of the
enterprise business unit at Red Hat, said.  Linux is a free
version of the Unix operating system that was developed by
Finnish programmer Linus Torvalds and a network of
programmers. It is an alternative to Microsoft Corp.'s
Windows NT for some applications.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Faster Malloc

[Emery Berger]

Alfred Perlstein <[EMAIL PROTECTED]> wrote:

(regarding Hoard: )

> This allocator is pretty much what the Dynix allocator is, it wouldn't be
> difficult to clean-room implement this with a BSD license.
>
> They should have given credit to Dynix or at least Uresh Vahalia
> (discussed on page 390 of his book Unix Internals section 12.9).

Hi all,

The DYNIX kernel allocator was by McKenney and Slingwine, and I'll be
citing them in a revised version of the paper.

While there are a number of differences between my allocator (Hoard) and
theirs, the most important are locality related. I'll just bring up one
here: false sharing. Using the McKenney & Slingwine allocator (or the
new Cilk allocator, discussed in my paper), a cache line can end up
distributed across every CPU's free list and repeatedly re-used. This
happens because freed blocks are placed back on a CPU's own freelist.
This effect has been observed in practice and can dramatically worsen
application performance.

Hoard prevents this effect. Each superblock is owned by exactly one
processor. When processor A free()'s a block from another CPU's
superblock, it is put back in the superblock, and so will not be re-used
by processor A's next malloc().

Regards,
-- Emery

--
Emery Berger   | Parallel Programming
[EMAIL PROTECTED]| & Multiprogramming MP Groups 
 | University of Texas at Austin


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: firewall problem?

[Jonathan M. Bresler]

your ip address 62.20.54.54 is not in DNS, you must have your
address in DNS.  we do not accept email from machines that do not have
entries in DNS.  amny spammer use addresses that do not appear in DNS

jmb


> Delivered-To: [EMAIL PROTECTED]
> Delivered-To: [EMAIL PROTECTED]
> X-Mailer: TjohooMAIL
> X-WebsiteUser-IP: 62.20.54.54
> From: Ralph Utbult <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: Quoted-printable
> Date: Thu,  9 Dec 1999 03:35:26 -0800 (PST)
> Sender: [EMAIL PROTECTED]
> X-Loop: FreeBSD.ORG
> Precedence: bulk
> 
> Hi
> 
> I=B4m sitting behind a firewall consisting av FreeBsd and Squid. My mail pr=
> ogram is Popper. I can mail to (and from) every adress I=B4ve tried - excep=
> t freebsd.org. Here=B4s the error.
> The original message was received at Wed, 8 Dec 1999 16:40:08 +0100 (CET)
> from [192.168.1.2]
> 
> 
>- The following addresses had transient non-fatal errors -
> <[EMAIL PROTECTED]>
> 
> 
>- Transcript of session follows -
> .. while talking to hub.freebsd.org.:
> >>> RCPT To:<[EMAIL PROTECTED]>
> <<< 450 Client host rejected: cannot find your hostname, [62.20.54.54]
> <[EMAIL PROTECTED]>... Deferred: 450 Client host rejected: cannot=
>  find your hostname, [62.20.54.54]
> Warning: message still undelivered after 4 hours
> Will keep trying until message is 5 days old
> Reporting-MTA: dns; hyndan.gbg.abf.se
> Arrival-Date: Wed, 8 Dec 1999 16:40:08 +0100 (CET)
> 
> 
> Final-Recipient: RFC822; [EMAIL PROTECTED]
> Action: delayed
> Status: 4.2.0
> Remote-MTA: DNS; hub.freebsd.org
> Diagnostic-Code: SMTP; 450 Client host rejected: cannot find your hostname,=
>  [62.20.54.54]
> Last-Attempt-Date: Wed, 8 Dec 1999 20:52:11 +0100 (CET)
> Will-Retry-Until: Mon, 13 Dec 1999 16:40:08 +0100 (CET)
> Return-Path: <[EMAIL PROTECTED]>
> Received: from ralph ([192.168.1.2])
> by hyndan.gbg.abf.se (8.9.3/8.9.3) with ESMTP id QAA63400;
> Wed, 8 Dec 1999 16:40:08 +0100 (CET)
> Message-Id: <[EMAIL PROTECTED]>
> X-Sender: [EMAIL PROTECTED]
> X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
> Date: Wed, 08 Dec 1999 17:45:52 +0100
> To: [EMAIL PROTECTED]
> From: Ralph Utbult <[EMAIL PROTECTED]>
> Subject: Test - ignore!
> Cc: [EMAIL PROTECTED]
> Mime-Version: 1.0
> Content-Type: text/plain; charset=3D"iso-8859-1"; format=3Dflowed
> 
> What is the problem?
> 
> Regards,
> Ralph Utbult
> Systems Operator
> ABF G=F6teborg
> Sweden
> 
> Gratis epost med TJOHOOMAIL
> http://www.tjohoo.se
> 
> 
> 
> 
> 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

Re: question about boot loaders

[Doug White]

On Thu, 9 Dec 1999, Robert Watson wrote:

> loaderloadedbyfunction
> 
> mbr   BIOSwhatever, maybe a couple of lines

/boot/mbr is a copy of the classic DOS MBR code.  Used by fdisk.  Simply
loads the partition marked as 'active' (flag 0x80).

Everything else was covered in Neil's handbook piece (which I should
probably grab & commit! :-) )

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

Re: Possible libc changes to support LinuxThreads

[Richard Seaman, Jr.]

On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote:

> In this case, you'd want, for example, an _lseek(), _libc_lseek(),
> and _seek().  

I meant "and lseek()", not _seek().

-- 
Richard Seaman, Jr.   email: [EMAIL PROTECTED]
5182 N. Maple Lanephone: 262-367-5450
Chenequa WI 53058 fax:   262-367-5852


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Veritas Software Now Shipping With Linux

[Matthew Jacob]

Yes- this also concerned and annoyed the folks at Legato. It puts *me* in
a bit of a bind because I have had business ties to both companies (I
still do (at a very slow rate) Legato NetWorker client packages for *BSD
and non-Intel Linux).



On Thu, 9 Dec 1999, Charles Randall wrote:

> http://news.excite.com/news/r/991209/09/tech-veritas-linux
> 
> Veritas Software Now Shipping With Linux
> 
> MOUNTAIN VIEW, Calif. (Reuters) Veritas Software
> Corp. (VRTS.O) said on Thursday its software used to backup
> data on computer systems is being shipped with Red Hat
> Inc.'s Linux 6.1 Delux product.
> 
> "This is the first step as a result of the agreement we
> announced in early November to jointly develop enterprise
> storage management solutions for the Red Hat Linux
> marketplace," Paul McNamara, general manager of the
> enterprise business unit at Red Hat, said.  Linux is a free
> version of the Unix operating system that was developed by
> Finnish programmer Linus Torvalds and a network of
> programmers. It is an alternative to Microsoft Corp.'s
> Windows NT for some applications.
> 
> 
> 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

printf() from KLD

[Alex]

This message was sent from Geocrawler.com by "Alex" <[EMAIL PROTECTED]>
Be sure to reply to that address.

Hello,

I use printf() function from my KLD for 
debugging. Always, when the kernel call printf, I 
see two same line, like :
Dec 9 15:40:10 techno /kernel: 
Dec 9 15:40:10 techno /kernel: 

How can I remvoe second line?
Thank you.

Geocrawler.com - The Knowledge Archive


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Possible libc changes to support LinuxThreads

[Jason Evans]

On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote:
> On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote:
> 
> The problem with cancellation points, libc and linuxthreads has been
> that you need to wade through libc and replace instances of, for 
> example, write() with either _write() or _libc_write() in order to
> avoid propagating cancellation points where they don't belong.

Now I understand why you claimed that making cancellation work is a lot of
work.  Since that isn't currently done, do you think it would be better to
leave broken cancellation in the LinuxThreads port, or to take it out?  As
things stand right now, "broken" means:

1) Not all mandatory cancellation points are implemented.
2) Some functions may act as cancellation points, even though they
   shouldn't.

We can fix 1) with some symbol munging, but 2) is much more difficult, as
you point out.

> > The other issue has to do with longjmp() and siglongjmp(), and is of a
> > similar nature, except that _longjmp() already exists as a separate
> > interface.  So, at least in the case of longjmp(), it needs to have a
> > different alias, perhaps __longjmp().  Below is a *very* simplistic patch
> > to libc that works, but it may make some people's skin crawl.  Feedback is
> > welcome.  If there is no correct way to create aliases to function entry
> > points, then we can do without them, but it will mean that the *jmp()
> > functions cannot be used in conjunction with thread cleanup handlers when
> > using LinuxThreads.
> 
> __longjmp() and __siglongjmp() don't bother me at all.

Following is a slightly better patch that uses weak aliases.  longjmp()
must be an alias for __longjmp() since _longjmp() is a public interface.
However, siglongjmp() could be an alias for either _siglongjmp() or
__siglongjmp().  Is _siglongjmp() more consistent?

Of course, this doesn't matter at all if we leave out cancellation
entirely.

Index: i386/gen/setjmp.S
===
RCS file: /home/ncvs/src/lib/libc/i386/gen/setjmp.S,v
retrieving revision 1.11
diff -u -r1.11 setjmp.S
--- setjmp.S1999/10/10 08:38:33 1.11
+++ setjmp.S1999/12/09 20:53:11
@@ -54,7 +54,9 @@
 #include "DEFS.h"
 #include "SYS.h"
 
-ENTRY(setjmp)
+ENTRY(__setjmp)
+.weak setjmp;
+.set setjmp, __setjmp;
movl4(%esp),%ecx
PIC_PROLOGUE
leal28(%ecx), %eax
@@ -80,7 +82,9 @@
xorl%eax,%eax
ret
 
-ENTRY(longjmp)
+ENTRY(__longjmp)
+.weak longjmp;
+.set longjmp, __longjmp;
movl4(%esp),%edx
PIC_PROLOGUE
pushl   $0  /* (sigset_t*)oset */
Index: i386/gen/sigsetjmp.S
===
RCS file: /home/ncvs/src/lib/libc/i386/gen/sigsetjmp.S,v
retrieving revision 1.13
diff -u -r1.13 sigsetjmp.S
--- sigsetjmp.S 1999/09/29 15:18:35 1.13
+++ sigsetjmp.S 1999/12/09 20:53:11
@@ -59,7 +59,9 @@
  * use sigreturn() if sigreturn() works.
  */
 
-ENTRY(sigsetjmp)
+ENTRY(__sigsetjmp)
+.weak sigsetjmp;
+.set sigsetjmp, __sigsetjmp;
movl8(%esp),%eax
movl4(%esp),%ecx
movl%eax,44(%ecx)
@@ -89,7 +91,9 @@
xorl%eax,%eax
ret
 
-ENTRY(siglongjmp)
+ENTRY(__siglongjmp)
+.weak siglongjmp;
+.set siglongjmp, __siglongjmp;
movl4(%esp),%edx
cmpl$0,44(%edx)
jz  2f


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: printf() from KLD

[Archie Cobbs]

Alex writes:
> This message was sent from Geocrawler.com by "Alex" <[EMAIL PROTECTED]>
> Be sure to reply to that address.
> 
> Hello,
> 
> I use printf() function from my KLD for 
> debugging. Always, when the kernel call printf, I 
> see two same line, like :
> Dec 9 15:40:10 techno /kernel: 
> Dec 9 15:40:10 techno /kernel: 
> 
> How can I remvoe second line?
> Thank you.

man syslog.conf

Your message is matching more than one rule (eg, "root" and "console").

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Possible libc changes to support LinuxThreads

[Daniel Eischen]

Jason Evans wrote:
> On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote:
> > On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote:
> > 
> > The problem with cancellation points, libc and linuxthreads has been
> > that you need to wade through libc and replace instances of, for 
> > example, write() with either _write() or _libc_write() in order to
> > avoid propagating cancellation points where they don't belong.
> 
> Now I understand why you claimed that making cancellation work is a lot of
> work.  Since that isn't currently done, do you think it would be better to
> leave broken cancellation in the LinuxThreads port, or to take it out?  As
> things stand right now, "broken" means:
> 
> 1) Not all mandatory cancellation points are implemented.
> 2) Some functions may act as cancellation points, even though they
>shouldn't.
> 
> We can fix 1) with some symbol munging, but 2) is much more difficult, as
> you point out.

Have you looked at what NetBSD did with namespace?  See:

  
http://www.freebsd.org/cgi/cvsweb.cgi/basesrc/lib/libc/include/namespace.h?rev=1.42&cvsroot=netbsd

Dan Eischen
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Sequence of Events in Kernel source?

[Julian Elischer]

On Thu, 9 Dec 1999, Etienne De Bruin wrote:

> 
> 
> Greetings Seniors.
> 
> I am interested in establishing the sequence of events from a source code
> perspective from when the PC is switched on, to the login prompt.  I am
> specifically interested in the setting up of lower level stuff like the drivers.
> memory etc.
> 
> Can anyone please take a moment and give me some pointers?
> 
> Kind regards
> 
> eT
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 
check the old bootblocks
/usr/src/sys/i386/boot/biosboot for README.386BSD, README.MACH,
README.serial for some background.

then try find documentation (good luck) on the NEW bootblocks

/usr/src/sys/boot/README is a start.

The kernel starts in /sys/i386/i386/locore.s (at btext I think)
then goes (from memory) to main() via mi_startup (I think).
mi_startup is in init_main.c.

mi_startup calls all teh initialisation modules linked into the kernel.
(see kernel.h)

eventually it starts up init..





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Possible libc changes to support LinuxThreads

[Richard Seaman, Jr.]

On Thu, Dec 09, 1999 at 12:57:45PM -0800, Jason Evans wrote:
> On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote:
> > On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote:
> > 
> > The problem with cancellation points, libc and linuxthreads has been
> > that you need to wade through libc and replace instances of, for 
> > example, write() with either _write() or _libc_write() in order to
> > avoid propagating cancellation points where they don't belong.
> 
> Now I understand why you claimed that making cancellation work is a lot of
> work.  Since that isn't currently done, do you think it would be better to
> leave broken cancellation in the LinuxThreads port, or to take it out?  As
> things stand right now, "broken" means:
> 
> 1) Not all mandatory cancellation points are implemented.
> 2) Some functions may act as cancellation points, even though they
>shouldn't.
> 
> We can fix 1) with some symbol munging, but 2) is much more difficult, as
> you point out.

I think #2 above is very dangerous, since you can get a cancellation
point unexpectedly while the thread holds resources (eg a lock).  If
you cancel while holding a lock, you could deadlock.  This could even
happen within libc, where (for example) fread puts a lock around
the read syscall.  If read is a cancellation point, the libc lock for
the FILE pointer won't get released (at least I don't think it will).
A user app could have the same problem if there are unexpected cancellation
points.

The original linuxthreads port left the cancellation functions in,
but didn't do any syscall wrapping to implement libc cancellation
points.  A user app can create cancellation points with 
pthread_test_cancel(), which helps a little, but he doesn't get
the POSIX libc cancellation points.

Actually, I don't think all that many apps use pthread_cancel().
Its kind of messy to use.  Most can get along without it, which
is why there have only been a limited number of complaints about
the lack of pthread_cancel() in libc_r (until recently).  BTW,
I haven't looked at libc_r's new cancellation functions.  How do
they avoid propagating cancellation points in libc without
changing libc?  Maybe they have an idea that can be used here?

-- 
Richard Seaman, Jr.   email: [EMAIL PROTECTED]
5182 N. Maple Lanephone: 262-367-5450
Chenequa WI 53058 fax:   262-367-5852


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: question about boot loaders

[Mike Smith]

> 
> The documentation in /usr/src/sys/boot/i386 seems a little scant, and that
> still hanging out in /usr/src/sys/i386/boot is clearly outdated.  Was
> wondering if someone could point me at docs, and/or post a short summary
> something in the form of:

http://www.freebsd.org/~msmith/FTL/tutorials/bootloader.txt

It's incomplete and a little out of date, but I think it covers the 
questions you're asking.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: printf() from KLD

[Mike Smith]

> This message was sent from Geocrawler.com by "Alex" <[EMAIL PROTECTED]>
> Be sure to reply to that address.
> 
> Hello,
> 
> I use printf() function from my KLD for 
> debugging. Always, when the kernel call printf, I 
> see two same line, like :
> Dec 9 15:40:10 techno /kernel: 
> Dec 9 15:40:10 techno /kernel: 
> 
> How can I remvoe second line?

Read the manpages related to syslogd(8)

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PCI DMA lockups in 3.2 (3.3 maybe?)

[Pat Lynch]

We are having a similar problem at the job I just started. A box meeting
the exact specifications that Mike said caused the problem is essentially
having the crap beat out of it as far as disk access and network activity
(it might help to also say that this company is rather large in the scheme
of things and would be a good example of how to use FreeBSD in a large
enterprise environment). It is the only box out of alot of them having
this problem, but its also the only one thats getting beat up as much as
this one.

it would be great if Peter could post his "patch" for the problem (how to
migrate the -CURRENT driver into the 3.3 source) from what you say, Ed, it
stands up a bit better than the current driver does, and can only probably
get better. While this machine will probably be replaced with a different
machine, FreeBSD is somewhat of a "Pride and Joy" here. 

-Pat

--

Pat Lynch   [EMAIL PROTECTED]
[EMAIL PROTECTED]
Systems Administrator   Rush Networking




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Possible libc changes to support LinuxThreads

[Daniel Eischen]

Richard Seaman, Jr. wrote:
> Actually, I don't think all that many apps use pthread_cancel().
> Its kind of messy to use.  Most can get along without it, which
> is why there have only been a limited number of complaints about
> the lack of pthread_cancel() in libc_r (until recently).  BTW,
> I haven't looked at libc_r's new cancellation functions.  How do
> they avoid propagating cancellation points in libc without
> changing libc?  Maybe they have an idea that can be used here?

Hi Richard,

Libc_r doesn't avoid propagating cancellation points.  A read()
from within a libc(_r) function will still be a cancellation
point.

We had to weigh the lack of having pthread_cancel() versus
having pthread_cancel() with non-standard cancellation points.
In the end, only those applications that use pthread_cancel()
are affected.  I think the number of complaints saying "Hey,
pthread_cancel support has non-standard cancellation points"
will be less than the number of complaints because we don't
have _any_ pthread_cancel support.

Well, that's what I hope anyways ;-)  Time will probably prove
me wrong...

Dan Eischen
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Possible libc changes to support LinuxThreads

[Richard Seaman, Jr.]

On Thu, Dec 09, 1999 at 05:41:09PM -0500, Daniel Eischen wrote:
> Richard Seaman, Jr. wrote:
> > Actually, I don't think all that many apps use pthread_cancel().
> > Its kind of messy to use.  Most can get along without it, which
> > is why there have only been a limited number of complaints about
> > the lack of pthread_cancel() in libc_r (until recently).  BTW,
> > I haven't looked at libc_r's new cancellation functions.  How do
> > they avoid propagating cancellation points in libc without
> > changing libc?  Maybe they have an idea that can be used here?
> 
> Hi Richard,
> 
> Libc_r doesn't avoid propagating cancellation points.  A read()
> from within a libc(_r) function will still be a cancellation
> point.

Hmm..

What happens with (for example) fread() ?

fread, in the thread safe version, can be:

   lock FILE pointer
   read
   unlock FILE pointer

If fread is a cancellation point, don't you end up with
the lock held still?  Or, I guess since you keep track of
lock owners you can unwind the locks if the thread cancels?

-- 
Richard Seaman, Jr.   email: [EMAIL PROTECTED]
5182 N. Maple Lanephone: 262-367-5450
Chenequa WI 53058 fax:   262-367-5852


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Possible libc changes to support LinuxThreads

[Daniel Eischen]

On Thu, 9 Dec 1999, Richard Seaman, Jr. wrote:

> On Thu, Dec 09, 1999 at 05:41:09PM -0500, Daniel Eischen wrote:
> > Richard Seaman, Jr. wrote:
> > > Actually, I don't think all that many apps use pthread_cancel().
> > > Its kind of messy to use.  Most can get along without it, which
> > > is why there have only been a limited number of complaints about
> > > the lack of pthread_cancel() in libc_r (until recently).  BTW,
> > > I haven't looked at libc_r's new cancellation functions.  How do
> > > they avoid propagating cancellation points in libc without
> > > changing libc?  Maybe they have an idea that can be used here?
> > 
> > Hi Richard,
> > 
> > Libc_r doesn't avoid propagating cancellation points.  A read()
> > from within a libc(_r) function will still be a cancellation
> > point.
> 
> Hmm..
> 
> What happens with (for example) fread() ?
> 
> fread, in the thread safe version, can be:
> 
>lock FILE pointer
>read
>unlock FILE pointer
> 
> If fread is a cancellation point, don't you end up with
> the lock held still?  Or, I guess since you keep track of
> lock owners you can unwind the locks if the thread cancels?

Yes, we keep track of all internal locks and release them when
the thread is cancelled.  The only think not released just yet
are standalone (not part of other locks, like file, mutex,
condvar, etc) spinlocks.  For instance the spinlock that protects
malloc() wouldn't be released.  It's easy enough to fix those
with setting/clearing of lock wanted flags and/or held lock
counts, but I'd thought I'd try to borrow a trick from the
SA paper.

Dan Eischen
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Crypto in the kernel: where & how?

[Archie Cobbs]

What is the plan (if any) for including crypto stuff in the kernel?
As time goes on this will be more and more needed, eg. for IPSec
and other VPN applications.

It would be nice if we had a /usr/src/sys/crypt directory, plus whatever
export-controlled firewalling silliness is necessary.

Proposal.. (to get things started)

  - Add /usr/src/sys/crypt directory
  - Put exportable crypto stuff in it, eg, md5.c.
  - Put non-exportable crypto stuff in the international repository
(which is where?) .. and possibly a separate US repository (?)
(Or can the CVSup mirrors be configured not to mirror it?)

My ulterior motive is to checkin netgrapph/ng_mppc.c which adds
MPPE/MPPC support for PPTP.  However it's useless without an [A]RC4
implementation.

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Crypto in the kernel: where & how?

[Jason Thorpe]

On Thu, 9 Dec 1999 17:01:38 -0800 (PST) 
 Archie Cobbs <[EMAIL PROTECTED]> wrote:

 > What is the plan (if any) for including crypto stuff in the kernel?
 > As time goes on this will be more and more needed, eg. for IPSec
 > and other VPN applications.

At NetBSD, we already solved this problem with some simple changes to
our config(8).

Also, we put e.g. md5 and sha1 in libkern (the kernel's `libc'), since
they're in libc for userland.

-- Jason R. Thorpe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Crypto in the kernel: where & how?

[Kris Kennaway]

On Thu, 9 Dec 1999, Archie Cobbs wrote:

> It would be nice if we had a /usr/src/sys/crypt directory, plus whatever
> export-controlled firewalling silliness is necessary.

It'd presumably have to be /usr/src/secure/sys to fit with our existing
distribution infrastructure.

>   - Add /usr/src/sys/crypt directory
^o

>   - Put exportable crypto stuff in it, eg, md5.c.
>   - Put non-exportable crypto stuff in the international repository
> (which is where?)

internat.freebsd.org, in south africa

> .. and possibly a separate US repository (?)
> (Or can the CVSup mirrors be configured not to mirror it?)

US sites mirror their crypto from freebsd.org, international ones from the
international repository. The preferred path is for code to be committed
by international people to the international repository, since it can be
imported from there back into the US - if we can avoid it we shouldn't
commit stuff to the US repository on its own since that prevents most of
our users (by geography) from accessing it. However at least in the case
of OpenSSL (which I'm planning to import into internat when I go home to
australia next week :-) the two will have to be divergent due to the
patent restrictions on RSA.

Kris



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Upgrading rdist to v6.1.5 in -CURRENT?

[C. Stephen Gunn]

On Tue, Dec 07, 1999 at 10:13:34PM -0500, C. Stephen Gunn wrote:

> I'll send-pr the recipe, and post a reference here when I document
> how I worked around some of the magnicomp guys's kludged
> makefiles/includes.

I've send-pr'd my attempt at getting this ready for import.  (bin/15390)

You can fetch a tarball (relative to /usr/src) from:

   http://www.physics.purdue.edu/~csg/rdist-freebsd.tar.gz

There's a readme file in what would become contrib/rdist/README-FreeBSD
that documents my pruning of the distribution, and applied patches.

I was a little disgusted with my soltion for building gram.h from
the yacc grammar for rdistd to use.  If someone with more make/import
experience sees a better solution, let me know.

 - Steve



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Crypto in the kernel: where & how?

[Mark Murray]

> What is the plan (if any) for including crypto stuff in the kernel?
> As time goes on this will be more and more needed, eg. for IPSec
> and other VPN applications.

The KAME/IPv6 guys have already brought this up; the agreement was
that...

> It would be nice if we had a /usr/src/sys/crypt directory, plus whatever
> export-controlled firewalling silliness is necessary.

...a sys/crypt/ directory should hold their DES code. :-)

> Proposal.. (to get things started)
> 
>   - Add /usr/src/sys/crypt directory

The CTM things aleady know about this dir.

> My ulterior motive is to checkin netgrapph/ng_mppc.c which adds
> MPPE/MPPC support for PPTP.  However it's useless without an [A]RC4
> implementation.

I'd like DES, arc4 and MD5/SHA for Yarrow.

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message