Re: /sys hierarchy
On 01-Jul-00 Jordan K. Hubbard wrote:
Yes he did. Talk to various committers and you'll see that many have
ideas where files should live. There have been long threads on this
issue that got nowhere. The reason things are in such a messy state is
when something new is brought in, or is changed suffiently much for a
repo copy the person take the chance to put the files where *they* think
they should live. Vs. where there would be consistency in the /sys tree.
Talking to "various committers" will only yield various opinions and
end up leading nowhere, however. Perhaps if someone were to take
it upon themselves to post a detailed proposal of where things should
be moved to, others could at least comment more authoritatively
(and substantially) on the topic rather than just engaging in more
vague hand-waving.
I feel masochistic at the moment, so here's a suggestion. Feel free
to rip it all up to pieces, ya'll. And to start off: I like green
bikesheds. (I.e. let's settle on something sensible and not get
_too_ involved, please, or just shoot the whole idea down and enjoy
our sphaghetti)
Current directory structure:
sys/
${MACHINE_ARCH}/ - MD stuff
conf/ - MD kernel config files
${MACHINE_ARCH}/- MD code
include/- MD includes
... - various MD modules such as binary compat
boot/ - bootstrap
${MACHINE_ARCH}/- MI boot code
cam/ - cam subsystem
coda/ - coda fs
compile/ - compile work directory
conf/ - MI kernel config files
contrib/ - 3rd party kernel code
crypto/ - kernel crypto code
ddb/ - DDB
dev/ - several device drivers
fs/ - one file system
gnu/ - GNU kernel code
i4b/ - ISDN support
isa/ - MI ISA base code and a few drivers such as joy0
isofs/- CD9660 fs
kern/ - MI kernel code such as new-bus, vfs, init, etc.
libkern/ - libc for the kernel
miscfs/ - several fs's such as deadfs, devfs, etc.
modules/ - skeleton for the modules
msdosfs/ - MS-DOS FAT fs
net/ - some network drivers such as ppp, slip, bpf, and
generic network interface support
netatalk/ - support for Appletalk network
netatm/ - support for ATM network sockets
netgraph/ - the spiffy netgraph system
netinet/ - IPv4, TCP, UDP
netinet6/ - IPv6, IPsec, TCP and UDP glue
netipx/ - IPX/SPX
netkey/ - undocumented key management protocol - RFC 2367
netnatm/ - native mode ATM
netncp/ - Netware client protocol
netns/- Xerox NS, including IDP and SP
nfs/ - NFS
ntfs/ - NTFS
nwfs/ - Netware FS
pccard/ - PC card drivers
pci/ - MI PCI code and some drivers, notably PCI network cards
posix4/ - random POSIX code bucket
svr4/ - SVR4 binary compatibility
sys/ - kernel includes
ufs/ - UFS, FFS, and MFS
vm/ - VM system
Ok (/me dons the asbestos suit, climbs into the concrete room and locks
the door.) Here is my proposal. It attempts to follow these loose guidelines:
- MD code under sys/${MACHINE_ARCH}
- device drivers (including bus's such as cam and usb) under sys/dev
- file systems under fs/
- networking under net/
sys/
${MACHINE_ARCH} - stay the same, except add boot/ subdir
boot/ - formerly sys/boot/${MACHINE_ARCH}
boot - just MI boot code now. Depending on portability
of ARC, possibly move boot/arc under
sys/alpha/boot
compile/ - no change
conf/ - move NOTES to here from sys/i386/conf, but leave
it the same for now
contrib/ - stay the same. It mirrors the organization of
sys/. For example, contrib'd device drivers under
contrib/sys/dev, which is where they are now.
crypto/ - no change
ddb/ - no change
dev/ - everything in there now plus some extras
cam/- formerly sys/cam
i4b/- formerly sys/i4b
isa/- formerly sys/isa, this just cintains the support
code for the ISA bus, actual device drivers such as
joy0 would move into sys/dev/mumble
pccard/ - formerly sys/pccard
pci/- formerly sys/pci, split up just as sys/isa
fs/ -
Re: perl, cron or sh bug
I am not shure, is this cron bug calling with ignoring SIGCHLD, sh bug, or perl bug. I think cron shouldn't call anything with SIGCHLD ignored. Yes, it was in cron/do_command.c (void) signal(SIGCHLD, SIG_IGN); What about re-allowing SIGCHLD after second fork (i.e.vfork), just before execle()? Any objections? Not from me, as long as the implications are understood... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sunday, July 02, 2000, John Baldwin wrote:
ip/ - IPv4, IPv6, and IPsec bits from sys/netinet{,6}
tcp/ - TCP""" "
udp/ - UDP""" "
Can this really be separated to such a degree? Since TCP and
UDP are inet protocols, do they _need_ to be separated this way?
--
|Chris Costello [EMAIL PROTECTED]
|You can't make a program without broken egos.
`-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, Jul 02, 2000 at 12:36:59AM -0700, John Baldwin wrote:
Ok (/me dons the asbestos suit, climbs into the concrete room and locks
the door.) Here is my proposal. It attempts to follow these loose guidelines:
compile/ - no change
I'd change this into compile/${MACHINE_ARCH} so that a single shared source
tree can be used to build [alpha,i386] kernels. In the current setup one
gets clashes with GENERIC etc.
--
Wilko Bulte http://www.freebsd.org "Do, or do not. There is no try"
[EMAIL PROTECTED] http://www.nlfug.nl Yoda - The Empire Strikes Back
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs-cur.6450.gz Fatal error: Bytecount too large.
On 2000-07-01 16:35 -0500, Stephen Hocking [EMAIL PROTECTED] wrote: After some absence from the net (my machines were in a box between Australia Houston) I've finaaly connected up and am updating my cvs repository via CTM again. However, when I attempt to apply cvs-cur.6450.gz I get the above error. Anybody got a good one? You have to increase the value of MAX_SIZE in /usr/src/usr.sbin/ctm/ctm/ctm.h to at least 12MB (i.e. 1024*1024*12). This has been fixed in -current (to 20MB) and is awaiting a MFC. Not sure whether the fix went in before cvs-cur.6450, but I think so. In that case just recompile and install ctm. Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PPPoE not working ?
PPPoE has stopped working since I made a new kernel today. Luckily, I still
have kernel.old, which works.
I don't know whether the problem is related to the randomdev changes, or
the stuff Archie has been doing with NETGRAPH.
I did notice that, using the old kernel and modules, I don't need a
ng_ether.ko for PPPoE to work, although I do see a complaint that it
can't be found. With the new kernel and modules PPPoE fails if the
ng_ether.ko isn't found (I moved it away to see if it was perhaps the
source of the problem).
Looking at tcpdump trace with the new kernel it almost looks like the
initial connect packets are not being sent to tun0, but I haven't
spent any time looking at it in detail.
Here's tcpdump output from a working connect and one that fails. Maybe
someone can see something obvious.
working connect (partial):
tcpdump: listening on ed0
22:05:08.252387 PPPoE PADI [Service-Name] [Host-Uniq UTF8]
0x 1109 000c 0101 0103 0004 0067...g
0x0010 01c1 ..
22:05:08.297194 PPPoE PADO [Service-Name] [Host-Uniq UTF8] [AC-Name
"MUNC31-nrp1
"] [AC-Cookie UTF8]
0x 1107 002f 0101 0103 0004 0067./.g
0x0010 01c1 0102 000b 4d55 4e43 3331 2d6e 7270..MUNC31-nrp
0x0020 3101 0400 1019 befa ff47 3ecf 52f3 7b7b1G.R.{{
0x0030 5b63 db31 75 [c.1u
22:05:08.297288 PPPoE PADR [Service-Name] [AC-Cookie UTF8] [AC-Name
"MUNC31-nrp1
"] [Host-Uniq UTF8]
0x 1119 002f 0101 0104 0010 19be./..
0x0010 faff 473e cf52 f37b 7b5b 63db 3175 0102..G.R.{{[c.1u..
0x0020 000b 4d55 4e43 3331 2d6e 7270 3101 0300..MUNC31-nrp1...
0x0030 0400 6701 c1 ..g..
22:05:08.342130 PPPoE PADS [ses 0x4cc] [Service-Name] [AC-Cookie UTF8]
[AC-Name
"MUNC31-nrp1"] [Host-Uniq UTF8]
0x 1165 04cc 002f 0101 0104 0010 19be.e.../..
0x0010 faff 473e cf52 f37b 7b5b 63db 3175 0102..G.R.{{[c.1u..
0x0020 000b 4d55 4e43 3331 2d6e 7270 3101 0300..MUNC31-nrp1...
0x0030 0400 6701 c1 ..g..
22:05:08.343051 PPPoE [ses 0x4cc] LCP ConfReq id=0x8f auth PAP magic
0xb4676
d72
0x 1100 04cc 0010 c021 018f 000e 0304 c023...!...#
0x0010 0506 b467 6d72 19be faff 473e cf52 f37b...gmrG.R.{
0x0020 7b5b 63db 3175 0102 000b 4d55 4e43 {[c.1uMUNC
failed connect:
tcpdump: listening on ed0
11:55:10.628019 PPPoE PADI [Service-Name] [Host-Uniq UTF8]
0x 1109 000c 0101 0103 0004 c090
0x0010 e1c0 ..
11:55:10.674248 PPPoE PADO [Service-Name] [Host-Uniq UTF8] [AC-Name
"MUNC31-nrp1"] [AC-Cookie UTF8]
0x 1107 002f 0101 0103 0004 c090./..
0x0010 e1c0 0102 000b 4d55 4e43 3331 2d6e 7270..MUNC31-nrp
0x0020 3101 0400 105b 0382 ce6b 426d 4ea3 884c1[...kBmN..L
0x0030 10da 4907 7c ..I.|
11:55:12.620895 PPPoE PADI [Service-Name] [Host-Uniq UTF8]
0x 1109 000c 0101 0103 0004 c090
0x0010 e1c0 ..
11:55:12.666009 PPPoE PADO [Service-Name] [Host-Uniq UTF8] [AC-Name
"MUNC31-nrp1"] [AC-Cookie UTF8]
0x 1107 002f 0101 0103 0004 c090./..
0x0010 e1c0 0102 000b 4d55 4e43 3331 2d6e 7270..MUNC31-nrp
0x0020 3101 0400 105b 0382 ce6b 426d 4ea3 884c1[...kBmN..L
0x0030 10da 4907 7c ..I.|
Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PPPoE not working
I see literally the exact same thing. I thought it was just my screwup, as i had installed 0609-CURRENT (the latest installs don't work, at least, on my desktop, so i picked the one from my birthday :P), which worked fine, then cvsup'd, installed the new kernel, did a make world, rebooted, and pppoe no longer worked. tcpdump shows the same thing you are seeing. --Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
could someone with committer access commit this?
This is the patch to make my soundcard, a Creative Ensoniq AudioPCI (an
es1371 chip, device id 0x58801274 rev 0x02). Can someone commit it please?
Thanks.
--- es137x.c.oldSun May 28 11:15:14 2000
+++ es137x.cSat Jul 1 23:22:00 2000
@@ -68,6 +68,7 @@
#define ES1370_PCI_ID 0x50001274
#define ES1371_PCI_ID 0x13711274
#define ES1371_PCI_ID2 0x13713274
+#define ES1371_PCI_ID3 0x58801274
#define ES_BUFFSIZE 4096
@@ -493,7 +494,7 @@
es-ctrl = 0;
es-sctrl = 0;
/* initialize the chips */
- if (rev == 7 || rev = 9) {
+ if (rev == 7 || rev = 9 || rev == 2) {
#define ES1371_BINTSUMM_OFF 0x07
bus_space_write_4(es-st, es-sh, ES1371_BINTSUMM_OFF, 0x20);
if (debug 0) printf("es_init rev == 7 || rev = 9\n");
@@ -724,7 +725,8 @@
device_set_desc(dev, "AudioPCI ES1370");
return 0;
} else if (pci_get_devid(dev) == ES1371_PCI_ID ||
- pci_get_devid(dev) == ES1371_PCI_ID2) {
+ pci_get_devid(dev) == ES1371_PCI_ID2 ||
+ pci_get_devid(dev) == ES1371_PCI_ID3) {
device_set_desc(dev, "AudioPCI ES1371");
return 0;
}
@@ -789,7 +791,8 @@
}
if (pci_get_devid(dev) == ES1371_PCI_ID ||
- pci_get_devid(dev) == ES1371_PCI_ID2) {
+ pci_get_devid(dev) == ES1371_PCI_ID2 ||
+ pci_get_devid(dev) == ES1371_PCI_ID3) {
if(-1 == es1371_init(es, pci_get_revid(dev))) {
device_printf(dev, "unable to initialize the card\n");
goto bad;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: could someone with committer access commit this?
According to Kenneth Wayne Culver: This is the patch to make my soundcard, a Creative Ensoniq AudioPCI (an es1371 chip, device id 0x58801274 rev 0x02). Can someone commit it please? Done. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: perl, cron or sh bug
On Sun, Jul 02, 2000 at 09:39:39AM +0200, Mark Murray wrote: I am not shure, is this cron bug calling with ignoring SIGCHLD, sh bug, or perl bug. I think cron shouldn't call anything with SIGCHLD ignored. Yes, it was in cron/do_command.c (void) signal(SIGCHLD, SIG_IGN); What about re-allowing SIGCHLD after second fork (i.e.vfork), just before execle()? Any objections? Not from me, as long as the implications are understood... I already solve this thing. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
regex(3) is leaking memory
I forgot to free the additional memory allocated by regcomp() at regfree(). So, for now, regex(3) is leaking memory. I'll fix it in a short while (but not immediately, sorry). -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] jkh _DES: The Book of Bruce has only one sentence in it, and it says "the actual directives of my cult are left as an exercise for the reader. Good luck." EE jkh: does it really include the 'good luck' part? jkh EE: OK, I made that part up. jkh EE: I figured it should sound a bit more cheery than how Bruce initially dictated it to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Possible bug in netinet6/in6_rmx.c ?
Hi, While working on adding dynamic sysctls support, I discovered something that looks like a bug. For kernels that have both INET and INET6, three sysctl entries (rtexpire, rtminexpire, rtmaxcache) are registered twice - both in netinet/in_rmx.c and netinet6/in6_rmx.c. It seems they should be registered only once, within a section that is common to INET and INET6. Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP! Perl version number change!
Hello!
Perl5's version number has had to change; it is no longer 5.006, now
it is 5.6.0 in accordance with Perl standards. I tried hard to keep
with established tradition, but this did not work.
${DEITY}, I hate the Perl build.
This means that you should get do a 'make world' and 'mergemaster'
to get all the directories and /etc area right (unless you know
what you are doing, of course :-) ).
Side effect; suidperl is no longer unreliable.
M
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Help with Linux interpreter
At Sat, 01 Jul 2000 21:25:42 -0600, Warner Losh [EMAIL PROTECTED] wrote: I was able to install the acroread4 port on my -current machine of a week or two ago. I find when I try to run acroread4 I get the following error: ELF interpreter /lib/ld-linux.so.2 not found Abort Please take a look into ports/18489. Workaround for i386 has been committed at 14th May but not for Alpha. I think you are on the Alpha plathome, or your ports tree is weirdly out of date. -- FUJISHIMA Satsuki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Help with Linux interpreter
On Sat, 1 Jul 2000, Warner Losh wrote: I was able to install the acroread4 port on my -current machine of a week or two ago. I find when I try to run acroread4 I get the following error: ELF interpreter /lib/ld-linux.so.2 not found Abort Did you brand acroread? Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On 02-Jul-00 Wilko Bulte wrote:
On Sun, Jul 02, 2000 at 12:36:59AM -0700, John Baldwin wrote:
Ok (/me dons the asbestos suit, climbs into the concrete room and locks
the door.) Here is my proposal. It attempts to follow these loose guidelines:
compile/ - no change
I'd change this into compile/${MACHINE_ARCH} so that a single shared source
tree can be used to build [alpha,i386] kernels. In the current setup one
gets clashes with GENERIC etc.
Sounds good to me actually. Although, should it be ${MACHINE_ARCH}/compile
instead in keeping with the mentioned goal of keeping all MD stuff under
${MACHINE_ARCH}?
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On 02-Jul-00 Chris Costello wrote:
On Sunday, July 02, 2000, John Baldwin wrote:
ip/ - IPv4, IPv6, and IPsec bits from sys/netinet{,6}
tcp/ - TCP""" "
udp/ - UDP""" "
Can this really be separated to such a degree? Since TCP and
UDP are inet protocols, do they _need_ to be separated this way?
A directory listing of sys/netinet shows many in_* files, ip_* files,
tcp_* files, and udp_* files. Note that TCP and UDP aren't explicity
tied to IP, they are simply wrapped inside of an IP packet. In theory
you can run TCP over IPX for example by using the same method of
encapsulation. Of course, someone more familiar with the actual code
in the tree might provide some better insight on the feasibility of
splitting these up.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sunday, July 02, 2000, John Baldwin wrote:
Sounds good to me actually. Although, should it be ${MACHINE_ARCH}/compile
instead in keeping with the mentioned goal of keeping all MD stuff under
${MACHINE_ARCH}?
I think that compile/${MACHINE_ARCH} is the proper way to do
this. Everything else is source only, all the object files end
up inside compile/ so there's only one place to clean up.
--
|Chris Costello [EMAIL PROTECTED]
|My reality check just bounced.
`--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On 02-Jul-00 Chris Costello wrote:
On Sunday, July 02, 2000, John Baldwin wrote:
ip/ - IPv4, IPv6, and IPsec bits from sys/netinet{,6}
tcp/ - TCP""" "
udp/ - UDP""" "
Can this really be separated to such a degree? Since TCP and
UDP are inet protocols, do they _need_ to be separated this way?
A directory listing of sys/netinet shows many in_* files, ip_* files,
tcp_* files, and udp_* files. Note that TCP and UDP aren't explicity
tied to IP, they are simply wrapped inside of an IP packet. In theory
you can run TCP over IPX for example by using the same method of
encapsulation. Of course, someone more familiar with the actual code
in the tree might provide some better insight on the feasibility of
splitting these up.
Well, in theory maybe, but note that the TCP checksum is computed
over a the TCP header and a pseudo header composed of the IPv4 transport
addresses. The layering of the protocols is a fine intellectual
notion, but don't confuse the layering with an efficient implementation.
louie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sunday, July 02, 2000, John Baldwin wrote:
Sounds good to me actually. Although, should it be ${MACHINE_ARCH}/compile
instead in keeping with the mentioned goal of keeping all MD stuff under
${MACHINE_ARCH}?
I think that compile/${MACHINE_ARCH} is the proper way to do
this. Everything else is source only, all the object files end
up inside compile/ so there's only one place to clean up.
Actually the whole src/sys/compile thing should go away, it is
one of the last things that has to be dealt with for a totally
read-only mounted /usr/src. IMHO it should be moved to /usr/obj,
and /usr/obj should, if it hasn't already, be enhanced to include
a ${MACHINE_ARCH} component.
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sunday, July 02, 2000, Rodney W. Grimes wrote:
Actually the whole src/sys/compile thing should go away, it is
one of the last things that has to be dealt with for a totally
read-only mounted /usr/src. IMHO it should be moved to /usr/obj,
and /usr/obj should, if it hasn't already, be enhanced to include
a ${MACHINE_ARCH} component.
It does already, but how do you propose the user build and
install the kernel? ``cd /usr/obj ...'' is inconsistent with any
current procedures.
--
|Chris Costello [EMAIL PROTECTED]
|If a program is useless, it must be documented.
`---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, Jul 02, 2000 at 11:06:58AM -0700, Rodney W. Grimes wrote:
On Sunday, July 02, 2000, John Baldwin wrote:
Sounds good to me actually. Although, should it be ${MACHINE_ARCH}/compile
instead in keeping with the mentioned goal of keeping all MD stuff under
${MACHINE_ARCH}?
I think that compile/${MACHINE_ARCH} is the proper way to do
this. Everything else is source only, all the object files end
up inside compile/ so there's only one place to clean up.
Actually the whole src/sys/compile thing should go away, it is
one of the last things that has to be dealt with for a totally
read-only mounted /usr/src. IMHO it should be moved to /usr/obj,
and /usr/obj should, if it hasn't already, be enhanced to include
a ${MACHINE_ARCH} component.
Yes, this is definitely the cleanest solution IMO.
--
Wilko Bulte http://www.freebsd.org "Do, or do not. There is no try"
[EMAIL PROTECTED] http://www.nlfug.nl Yoda - The Empire Strikes Back
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
...
I feel masochistic at the moment, so here's a suggestion. Feel free
to rip it all up to pieces, ya'll. And to start off: I like green
bikesheds. (I.e. let's settle on something sensible and not get
I prefer blue ones :-)
...
Ok (/me dons the asbestos suit, climbs into the concrete room and locks
the door.) Here is my proposal. It attempts to follow these loose guidelines:
Let me go hunting for flame thrower and concrete saw :-)
- MD code under sys/${MACHINE_ARCH}
- device drivers (including bus's such as cam and usb) under sys/dev
Perhaps, sys/bus and sys/dev, instead of lumping it all into one
sys/dev.
- networking under net/
That one is going to be a really really hard one over the longrun,
it is going to make the source code incompatible with every other
BSD based source tree requireing path mangling anytime something
is brought in from some place else. Especially look at what
this would do to the /usr/include/net* hierarchy and how that
effects userland code. Take a look at how many man pages this
would impact (to get an idea do ``cd /usr/share/man/man3;
zgrep netinet *''.)
sys/
...
net/ - move existing contents to net/base or something similar
...
atm/ - formerly sys/netatm
natm/- formerly sys/netatm
Ooopsss... natm/ should go away, you already have a better place for that :-)
ncp/ - formerly sys/netncp
ns/ - formerly sus/netns
^
We have no sus directory :-)
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Help with Linux interpreter
In message [EMAIL PROTECTED] Doug White writes: : ELF interpreter /lib/ld-linux.so.2 not found : Abort : : Did you brand acroread? Yes. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvs commit: ports/textproc/libxml2 Makefile ports/textproc/libxml2/files md5 ports/textproc/libxml2/pkg PLIST
On Sun, 2 Jul 2000 02:30:30 -0700 (PDT), Ade Lovett [EMAIL PROTECTED] said:
Bring libxml2 2.1.1 into the fold after a repo-copy. This will
eventually replace libxml for GNOME.
About a month ago, I was looking for a reasonable XML library with an
eye towards bringing one into the tree (to be used for config files
which have grown too complicated in syntax, like {,new}syslog.conf).
I didn't find one which met the desired criteria of:
- Reasonably small
- Provides a reasonable tree-based interface for C programs (i.e.,
not DOM or anything that looks remotely like it)
- Comes under a BSD-compatible license
Does anyone know of such a library?
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sunday, July 02, 2000, Rodney W. Grimes wrote:
Actually the whole src/sys/compile thing should go away, it is
one of the last things that has to be dealt with for a totally
read-only mounted /usr/src. IMHO it should be moved to /usr/obj,
and /usr/obj should, if it hasn't already, be enhanced to include
a ${MACHINE_ARCH} component.
It does already, but how do you propose the user build and
install the kernel? ``cd /usr/obj ...'' is inconsistent with any
current procedures.
Just the argument to the cd has changed, the command sequence is
still:
cd blah
make depend make make install.
cd blah is currently
cd ../../compile/${KERNNAME}
it becomes
cd /usr/obj/`pwd`/${KERNNAME}
config(8) will need to produce a better makefile using `pwd` to
figure out the path to the kernel sources. BDE probably has lots
of tips about how to do this.
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, 02 Jul 2000 10:44:23 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: encapsulation. Of course, someone more familiar with the actual code in the tree might provide some better insight on the feasibility of splitting these up. Don't, or else legions of network people will curse you to the end of your days. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA support..
In message [EMAIL PROTECTED] Julian Elischer writes: : Unfortunatly /etc/updateing doesn't warn you of this.. : I hit this as well. : What is in /etc/updating is so vague and nondescript that : it doesn't help wit this problem. (at least as it was when I hit it) There is no /etc/updating. UPDATING does contain information that you need. If you aren't able to figure out what you need to do based on reading it, don't run -current. 2625: From approximately this date forward, one must have the crypto system installed in order to build the system and kernel. While not technically strictly true, one should treat it as required and grab the crypto bits. If you are grabbing CVS trees, src-all and cvs-crypto should be treated as if they were required. You should check with the latest collections to make sure that these haven't changed. Seems pretty clear to me. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Xbatt now fails on -current
In message [EMAIL PROTECTED] Julian Elischer writes: : Is there something else I need to add? What do your hints look like? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
In message [EMAIL PROTECTED] "Rodney W. Grimes" writes:
: Just the argument to the cd has changed, the command sequence is
: still:
: cd blah
: make depend make make install.
:
: cd blah is currently
: cd ../../compile/${KERNNAME}
: it becomes
: cd /usr/obj/`pwd`/${KERNNAME}
:
: config(8) will need to produce a better makefile using `pwd` to
: figure out the path to the kernel sources. BDE probably has lots
: of tips about how to do this.
My take on this is that it would make it slightly harder to develop
kernel stuff in the tree. I don't like that prospect, and I think
this would impose some hardship on third parties that are using
FreeBSD. If it could be turned off, that would be ideal. It ties the
userland and kernel together too tightly, imho.
For the average buildworld, it might not be bad, however.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
"Rodney W. Grimes" wrote:
On Sunday, July 02, 2000, Rodney W. Grimes wrote:
Actually the whole src/sys/compile thing should go away, it is
one of the last things that has to be dealt with for a totally
read-only mounted /usr/src. IMHO it should be moved to /usr/obj,
and /usr/obj should, if it hasn't already, be enhanced to include
a ${MACHINE_ARCH} component.
It does already, but how do you propose the user build and
install the kernel? ``cd /usr/obj ...'' is inconsistent with any
current procedures.
Just the argument to the cd has changed, the command sequence is
still:
cd blah
make depend make make install.
If we're going to do this (and I'm all for anything that improves the
read-onliness of /usr/src) I suggest that we can hide all of the pain of
changing the process behind popularizing the buildkernel and
installkernel targets. Thus, when someone wants to paint the bikeshed
yellow in a few years the users won't have to be re-re-educated.
Doug
--
"Live free or die"
- State motto of my ancestral homeland, New Hampshire
Do YOU Yahoo!?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, Jul 02, 2000 at 12:36:59AM -0700, John Baldwin wrote:
Current directory structure:
sys/
${MACHINE_ARCH}/ - MD stuff
conf/ - MD kernel config files
${MACHINE_ARCH}/- MD code
include/- MD includes
... - various MD modules such as binary compat
They should be stated because they need to be moved
linux - Linux binary compat
Also buses
isa - there is some MI stuff in here
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, Jul 02, 2000 at 10:44:22AM -0700, John Baldwin wrote:
compile/ - no change
I'd change this into compile/${MACHINE_ARCH} so that a single shared source
tree can be used to build [alpha,i386] kernels. In the current setup one
gets clashes with GENERIC etc.
AS much as I hate this idea, I have to support it strongly.
Sounds good to me actually. Although, should it be ${MACHINE_ARCH}/compile
instead in keeping with the mentioned goal of keeping all MD stuff under
${MACHINE_ARCH}?
I would prefer /sys/compile/ARCH as it makes it easier to make a
symlink to another place. Unless of course we get /usr/obj working for
kernel compiles
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, Jul 02, 2000 at 01:31:28PM -0600, Warner Losh wrote:
: cd blah is currently
: cd ../../compile/${KERNNAME}
: it becomes
: cd /usr/obj/`pwd`/${KERNNAME}
My take on this is that it would make it slightly harder to develop
kernel stuff in the tree. I don't like that prospect, and I think
I agree that it is nicer to make the created headers, Makefile, etc. into
/sys/compile/ , BUT it would be better to put the .o's in /usr/obj/ to
seperate the generated binary from the [generated] source.
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
In message [EMAIL PROTECTED] "David O'Brien" writes:
: On Sun, Jul 02, 2000 at 01:31:28PM -0600, Warner Losh wrote:
: : cd blah is currently
: : cd ../../compile/${KERNNAME}
: : it becomes
: : cd /usr/obj/`pwd`/${KERNNAME}
:
: My take on this is that it would make it slightly harder to develop
: kernel stuff in the tree. I don't like that prospect, and I think
:
: I agree that it is nicer to make the created headers, Makefile, etc. into
: /sys/compile/ , BUT it would be better to put the .o's in /usr/obj/ to
: seperate the generated binary from the [generated] source.
Having the ability to do this is great (like I said for the typical
buildworld case). Having the ability to turn it off is also desirable
to aid in normal development. Even /usr/obj can be turned off for the
normal case by setting MAKEOBJDIRPREFIX to /bogus (assuming you have
no /bogus). So too should any new feature like this be. config
shouldn't be modified to put things in /usr/obj/`pwd`${KERNNAME}, but
instead one should use the -d feature of config in the buildkernel
target to put this into /usr/obj.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
make buildworld failed...
Hello! After CVSuped my sources i try make buildworld it failed: cc -O2 -pipe -march=pentium -DUNIX -fwritable-strings -I/usr/obj/usr/src/i386/usr/include -c /usr/src/games/rogue/thw.c cc -O2 -pipe -march=pentium -DUNIX -fwritable-strings -I/usr/obj/usr/src/i386/usr/include -c /usr/src/games/rogue/tr.c cc -O2 -pipe -march=pentium -DUNIX -fwritable-strings -I/usr/obj/usr/src/i386/usr/include -c /usr/src/games/rogue/usc cc -O2 -pipe -march=pentium -DUNIX -fwritable-strings -I/usr/obj/usr/src/i386/usr/include -c /usr/src/games/rogue/zac cc -O2 -pipe -march=pentium -DUNIX -fwritable-strings -I/usr/obj/usr/src/i386/usr/include -o rogue curses.o hit.o it.o inventory.o level.o machdep.o main.o message.o monster.o move.o object.o pack.o play.o random.o ring.o room.o save score.o spec_hit.o throw.o trap.o use.o zap.o -lcurses -ltermcap -lcompat monster.o: In function `mv_1_monster': monster.o(.text+0x657): undefined reference to `flame_broil' *** Error code 1 Stop in /usr/src/games/rogue. *** Error code 1 Stop in /usr/src/games. *** Error code 1 Any idea? Rgdz, Sergey Osokin aka oZZ, [EMAIL PROTECTED] http://www.FreeBSD.org.ru/~osa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: ports/textproc/libxml2 Makefile ports/textproc/libxml2/files md5 ports/textproc/libxml2/pkg PLIST
On Sun, 2 Jul 2000, Garrett Wollman wrote:
On Sun, 2 Jul 2000 02:30:30 -0700 (PDT), Ade Lovett [EMAIL PROTECTED] said:
Bring libxml2 2.1.1 into the fold after a repo-copy. This will
eventually replace libxml for GNOME.
About a month ago, I was looking for a reasonable XML library with an
eye towards bringing one into the tree (to be used for config files
which have grown too complicated in syntax, like {,new}syslog.conf).
I didn't find one which met the desired criteria of:
- Reasonably small
- Provides a reasonable tree-based interface for C programs (i.e.,
not DOM or anything that looks remotely like it)
- Comes under a BSD-compatible license
Does anyone know of such a library?
Hmm.. Expat (ports/textproc/expat)? There is also a 'lite' version
available. It provides SAX interface (which I personally like the
most). Mozilla license.
Andrzej Bialecki
// [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org
// --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs-cur.6450.gz Fatal error: Bytecount too large.
Stefan Esser wrote: On 2000-07-01 16:35 -0500, Stephen Hocking [EMAIL PROTECTED] wrote: again. However, when I attempt to apply cvs-cur.6450.gz I get the above err You have to increase the value of MAX_SIZE in /usr/src/usr.sbin/ctm/ctm/ctm.h to at least 12MB (i.e. 1024*1024*12). This has been fixed in -current (to 20M B) and is awaiting a MFC. Not sure whether the fix went in before cvs-cur.6450, but I think so. In that case just recompile and install ctm. The patch below solves it on 3.4-RELEASE : Date: Wed, 21 Jun 2000 09:18:26 -0400 (EDT) From: Chuck Robey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs-cur Message-ID: [EMAIL PROTECTED] .. Index: /usr/src/usr.sbin/ctm/ctm/ctm.h === RCS file: /usr/cvs/src/usr.sbin/ctm/ctm/ctm.h,v retrieving revision 1.14 diff -u -3 -r1.14 ctm.h - --- /usr/src/usr.sbin/ctm/ctm/ctm.h 1999/08/28 01:15:59 1.14 +++ /usr/src/usr.sbin/ctm/ctm/ctm.h 2000/06/15 20:25:55 @@ -26,7 +26,7 @@ #include sys/time.h #define VERSION "2.0" - -#define MAXSIZE (1024*1024*10) +#define MAXSIZE (1024*1024*20) #define SUBSUFF ".ctm" #define TMPSUFF ".ctmtmp" Julian - Julian Stacey http://bim.bsn.com/~jhs/ Kostenlos: FreeBSD 3200 packages, sources, Netscape, WordPerfect StarWriter. RaucherKrebsNebel erregt meinen allergischen Kopfschmerz: Schnupftabak Nutzen! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld failed...
According to Sergey Osokin: cc -O2 -pipe -march=pentium -DUNIX -fwritable-strings -I/usr/obj/usr/src/i386/usr/include -c /usr/src/games/rogue/thw.c Don't use "-O2" please. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld failed...
On Mon, Jul 03, 2000 at 01:09:25AM +0400, Sergey Osokin wrote: cc -O2 -pipe -march=pentium -DUNIX -fwritable-strings -I/usr/obj/usr/src/i386/usr/include -c /usr/src/games/rogue/thw.c You are adding to the long list of people that are about to make totally remove -02+ from GCC. FreeBSD only supports the use of -O in /usr/src/ -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld failed...
Sergey Osokin wrote: Hello! After CVSuped my sources i try make buildworld it failed: As you've already noticed, you will get better responses in general to help requests if you change your CFLAGS options in /etc/make.conf to "-O -pipe" (or just comment out CFLAGS, which has the same effect) and then try again. However... cc -c /usr/src/games/rogue/thw.c cc -c /usr/src/games/rogue/tr.c cc -c /usr/src/games/rogue/usc cc -c /usr/src/games/rogue/zac I don't see any of these files in my sources, are you sure this is FreeBSD's version of rogue? Also, using -current with the latest sources I can compile this cleanly in /usr/src/games/rogue, with optimization set to either "-Os -march=pentiumpro" or "-O2 -march=pentiumpro", so I'm not sure where your problem lies. Try it first without the optimization and see if that helps. BTW, -Os is generally preferred to -02, since the former enables almost everything that -O2 does, but is known to be less buggy. Good luck, Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Possible bug in netinet6/in6_rmx.c ?
On Sun, 2 Jul 2000, Andrzej Bialecki wrote: Hi, While working on adding dynamic sysctls support, I discovered something that looks like a bug. For kernels that have both INET and INET6, three sysctl entries (rtexpire, rtminexpire, rtmaxcache) are registered twice - both in netinet/in_rmx.c and netinet6/in6_rmx.c. It seems they should be registered only once, within a section that is common to INET and INET6. Andrzej Bialecki I think the real problem is that the rtexpire, rtminexpire, and rtmaxcache variables are each declared static in netinet/in_rmx.c and again in netinet6/in6_in6_rmx.c. Do we really need separate learned route expiration times for ip4 and ip6? If the answer is yes, then the solution should be to move the ip6 versions under the net.inet.ip6 sysctl tree. Otherwise, as you suggest, rtexpire and friends need to be common (maybe directly under net.inet?) By the way, while we are talking about sysctl, I don't suppose you would be willing to review/commit PR 15251? It is a fairly straightforward patch that fixes a number of signed-ness bugs with sysctl as well as fix certain sysctl variables to use the correct data type (mostly an issue when ints and longs are different sizes). Thanks, Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Help with Linux interpreter
In message [EMAIL PROTECTED] FUJISHIMA Satsuki writes: : Please take a look into ports/18489. : Workaround for i386 has been committed at 14th May but not for Alpha. : I think you are on the Alpha plathome, or your ports tree is weirdly : out of date. Everything is up to date. The kernel, my ports tree, userland. I still get this problem after updating to today's kernel/userland. Yes, ldconfig has been branded. ld.so has been branded. acroread (the binary that acroread4 runs, verified). I've enabled linux in the boot script (and verified that it runs). Any ideas about how I should go about debugging this? I need my acroread4 :-). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs-cur.6450.gz Fatal error: Bytecount too large.
On Sun, 2 Jul 2000, Julian Stacey wrote: Stefan Esser wrote: On 2000-07-01 16:35 -0500, Stephen Hocking [EMAIL PROTECTED] wrote: again. However, when I attempt to apply cvs-cur.6450.gz I get the above err You have to increase the value of MAX_SIZE in /usr/src/usr.sbin/ctm/ctm/ctm.h to at least 12MB (i.e. 1024*1024*12). This has been fixed in -current (to 20M B) and is awaiting a MFC. Not sure whether the fix went in before cvs-cur.6450, but I think so. In that case just recompile and install ctm. The patch below solves it on 3.4-RELEASE : Date: Wed, 21 Jun 2000 09:18:26 -0400 (EDT) From: Chuck Robey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs-cur Message-ID: [EMAIL PROTECTED] .. Index: /usr/src/usr.sbin/ctm/ctm/ctm.h === RCS file: /usr/cvs/src/usr.sbin/ctm/ctm/ctm.h,v retrieving revision 1.14 diff -u -3 -r1.14 ctm.h - --- /usr/src/usr.sbin/ctm/ctm/ctm.h 1999/08/28 01:15:59 1.14 +++ /usr/src/usr.sbin/ctm/ctm/ctm.h 2000/06/15 20:25:55 @@ -26,7 +26,7 @@ #include sys/time.h #define VERSION "2.0" - -#define MAXSIZE (1024*1024*10) +#define MAXSIZE (1024*1024*20) Yeah. I committed it to currect myself, Julian. Tomorrow, I'll do the MFC. It was about 2 weeks ago, when a big patch blew up the ctm machine. I announced it pretty widely on the ctm list, I'm really sorry you missed it and had to do that work again. #define SUBSUFF ".ctm" #define TMPSUFF ".ctmtmp" Julian - Julian Stacey http://bim.bsn.com/~jhs/ Kostenlos: FreeBSD 3200 packages, sources, Netscape, WordPerfect StarWriter. RaucherKrebsNebel erregt meinen allergischen Kopfschmerz: Schnupftabak Nutzen! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/gen Makefile.inc
Alexander Langer wrote: alex2000/07/02 14:45:16 PDT Modified files: lib/libc/gen Makefile.inc Log: Add strunvisx.3 MLINK. Revision ChangesPath 1.65 +2 -2 src/lib/libc/gen/Makefile.inc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe cvs-all" in the body of the message This breaks installworld, as the following diff: +MLINKS+=unvis.3 strunvis.3 strunvisx.3 should have been: +MLINKS+=unvis.3 strunvis.3 unvis.3 strunvisx.3 PYD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Small breakage in -Current, libc man page strunvisx.3.gz
I updated my sources this morning, and buildworld succeeded but installworld bombed out here while handling libc's man pages: /usr/share/man/man3/vis.3.gz - /usr/share/man/man3/strunvisx.3.gz ln: /usr/share/man/man3/strunvisx.3.gz: No such file or directory *** Error code 1 Stop in /usr/amd/realmounts/slave/usr/current/src/lib/libc. *** Error code 1 I had just did a 'make cleandir' and started with a clean /usr/obj right before this buildworld. I just cvsup'ed and didn't see anything that looked like it would make a difference. Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
