Re: Help with some makefile hackery
On Fri, 25 Jun 2010 05:57:24 -0700 Patrick Mahan ma...@mahan.org wrote:
src-kernel: src-kernel-tools
cd src; ./amd64-kernel.sh 21 | tee build_amd64_kernel.log
I've had the same issue teeing make output for coverage measurements.
A better way to write this might be
src-kernel: src-kernel-tools
rm -f src-kernel-done
{ cd src; ./amd64-kernel.sh 21 touch src-kernel-done; } | tee
build_amd64_kernel.log
rm src-kernel-done
You really want to catch all failures, including tee failures.
--
Brian Somers br...@awfulhak.org
Don't _EVER_ lose your sense of humour ! br...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: NFSD lockup running ESXi 4
On Wed, 9 Jun 2010 13:52:40 -0400 (EDT) r...@akira.stdio.com wrote: I have an AMD64 FreeBSD 8.0 running 8-Stable from around 2010/04/25 19:13:08. ZFS disk, Nfsd flags -t -n 16, private network exclusive for nfs network, not using jumbo frames, HZ=1000, Device_Polling, Zero_Copy_Sockets, and the following sysctl options: net.inet.tcp.recvspace=232140 net.inet.tcp.sendspace=232140 net.inet.tcp.slowstart_flightsize=159 net.inet.tcp.mssdflt=1460 FreeBSD 6 TB zpool, nfs from Three ESXi 4 (newest patch level 193498) working reliably for months. Added a new ESXi, patched to the newest (Post Update 1) patch level 256968. Added a bunch of VM's, booted them all into the 2008 R2 Server install DVD. Then when attempting to do the installs (in parallel/simultaneously) I started getting the NFS server locking up. NFSD would wedge at 100% CPU in rc_lo which I presume is rc_lock? Once wedged, /etc/rc.d/nfsd restart can't kill nfsd. So a reboot is required. A Reboot causes all my active VM's with pending disk writes to have disk errors in the VM (10 second default timeout for disk writes in the VM.) This was very reproducable. Has anyone noticed this problem? Is this an ESXi problem with the newest updates? Is this a problem with NFS on FreeBSD 8? I don't know if it's relevant, but I've been having nfs issues on -current. I believe they were caused by gam_server, a gnome program running on an NFS client machine that had /usr/ports nfs mounted and was doing a portupgrade. Nothing gnomeish should have been anywhere near /usr/ports, but analysis showed huge numbers of NFS stats against /usr/ports/distfiles/*, restat'ing the same files over and over. nfsd was going crazy on the server and gam_server was clocking up wads of CPU time on the client. FreeBSD-9 kernels prior to around June 6 were freezing on me. It may have been because of the nfsd activity, but I didn't investigate the freeze... Perhaps looking for changes that might might affect nfsd stability in the week prior to June 6 might discover a fix? -- Brian Somers br...@awfulhak.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org signature.asc Description: PGP signature
Re: head behaviour
On Mon, 07 Jun 2010 13:05:48 +0200, Dag-Erling Smørgrav d...@des.no wrote: Bakul Shah ba...@bitblocks.com writes: Except read doesn't do it quite right: $ ps | (read a; echo $a ; grep zsh) PID TT STAT TIME COMMAND yeah, I forgot that it drops leading whitespace... Well, leading $IFS $ ps | (IFS= read a; echo $a; grep zsh) works a lot better. -- Brian Somers br...@awfulhak.org Don't _EVER_ lose your sense of humour !br...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
On Tue, 25 Aug 2009 03:40:54 -0700 Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. To clarify, my proposal is to silently ignore the -w switch (any/all of them) and to remove the code that reads the terminal width and truncates some columns based on the result (or based on 132). The pros: - ps's code becomes simpler. It was mentioned that the ps code is a minefield. This would remove a few mines. - ps IMHO has no business knowing about terminal widths (and where did the 132 column -w idea come from again?). Some programs such as iostat have similar (but way more broken) behaviour however whilst others such as ls do not. - We remove the sizing bugs (only some columns are truncation victims). The cons: - people with visual expectations would have to learn to use less -S or some similar tool. This breaks POLA. - Scripts may exist that depend on the behaviour without -w. Furthermore having to handle ps from both before and after such a change in one script can be painful. It was also suggested that rather than changing the behaviour of one flavour of ps it would be better to adopt an approach more like linux's or even implementing POSIXs suggestions. AFAIK the linux suggestion has been on the table for more time than I care to remember (wasn't Brett Glass going to provide a patch soon?). Although I haven't read the linux code, I'm pretty sure it's a scary place - perhaps this is the reason that we don't have those patches yet. Unless others have more to say on the subject, I think it's clear that the most popular vote is to do nothing. I think this is a shame as I find the pros more compelling than the cons, and I'm sure there are more than a few supporters out there on hackers@ that will stay silent. -- Brian Somers br...@awfulhak.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org signature.asc Description: PGP signature
Deprecating ps(1)s -w switch
I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. -- Brian Somers br...@awfulhak.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org signature.asc Description: PGP signature
Re: kernel panics in in_lltable_lookup (with INVARIANTS)
On Fri, 21 Aug 2009 22:41:34 -0700 Brian Somers br...@awfulhak.org wrote:
On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers br...@freebsd.org wrote:
On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy km...@freebsd.org wrote:
Try this:
Index: sys/net/flowtable.c
===
--- sys/net/flowtable.c (revision 196382)
+++ sys/net/flowtable.c (working copy)
@@ -688,6 +688,12 @@
struct rtentry *rt = ro-ro_rt;
struct ifnet *ifp = rt-rt_ifp;
+ if (ifp-if_flags IFF_POINTOPOINT) {
+ RTFREE(rt);
+ ro-ro_rt = NULL;
+ return (ENOENT);
+ }
+
if (rt-rt_flags RTF_GATEWAY)
l3addr = rt-rt_gateway;
else
You'll need to apply this by hand as gmail munges the formatting.
-Kip
Hi,
That certainly stops the panic, however data routed to the tun
interface doesn't come out the back end and data written
to the back end doesn't come out the tun interface.
[.]
Maybe this problem isn't a routing problem. I'll
look into it further and figure out if the packet is getting to the tun
driver and if so, what it thinks it's doing with it.
I wasn't correct - the data *IS* being read out of the back of
the tunnel device. When I send the ICMP, it goes into the tun
device and comes out the back end as an AF_LINK packet. ppp
silently discards this (ironically I have a comment noting
that I should really track unidentified packet counts).
I'll try to figure out what in if_tun.c is corrupting the family next...
if_tun.c is fine. The data passed from if_output() has family
AF_LINK - hence the original panic from flowtable_lookup().
So the question is why is ip_output() sending AF_LINK traffic
instead of AF_INET traffic?.
Still looking
On Fri, Aug 21, 2009 at 16:43, Brian Somersbr...@freebsd.org wrote:
Hi,
I've been working on a fix to address an issue that came up with
our update of openssh-5. The issue is that openssh-5 now uses
pipe() to create stdin/stdout channels between sshd and the server
side program where it used to use socketpair(). Because it uses
pipe(), stdin is no longer bi-directional and cannot be used for both
input and output by a child process. This breaks the use of ssh
as a tunnel with ppp on either end (set device !ssh -e none host
ppp -direct label)
I talked with des@ for a while and then with the openssh folks and
have not been able to resolve the issues in openssh that made them
choose to enforce the use of pipe() over socketpair(). I now have a
patch to ppp that makes ppp detect that it's connected via pipe() and
causes it to use stdin for input and stdout for output (usually it
expects
just one descriptor). Although I'm happy with the patch and planned on
requesting permission to commit, I've bumped into a show-stopper
that seems unrelated, so I thought I'd ask here if anyone has seen
this or has any suggestions as to what the problem might be.
The issue
I'm seeing a panic when I send traffic through a ppp link:
panic string is: sin_family 18
Stack trace starts:
in_lltable_lookup()
llentry_update()
flowtable_lookup()
ip_output()
The panic is due to a KASSERT in in_lltable_lookup() that expects the
sockaddr to be AF_INET. Number 18 is AF_LINK.
AFAICT this is happening while setting up a temporary route for the
first outbound packet. I haven't been able to do much investigation
yet due to other patches in my tree that seem to have broken all my
kernel symbols, but once I get a clean rebuild I should be back in
business.
If anyone has any suggestions, I'm all ears!
Cheers.
--
Brian Somers br...@awfulhak.org
Don't _EVER_ lose your sense of humour ! br...@freebsd.org
signature.asc
Description: PGP signature
Re: kernel panics in in_lltable_lookup (with INVARIANTS)
On Fri, 21 Aug 2009 23:23:13 -0700 Brian Somers br...@freebsd.org wrote:
On Fri, 21 Aug 2009 22:41:34 -0700 Brian Somers br...@awfulhak.org wrote:
On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers br...@freebsd.org wrote:
On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy km...@freebsd.org wrote:
Try this:
Index: sys/net/flowtable.c
===
--- sys/net/flowtable.c (revision 196382)
+++ sys/net/flowtable.c (working copy)
@@ -688,6 +688,12 @@
struct rtentry *rt = ro-ro_rt;
struct ifnet *ifp = rt-rt_ifp;
+ if (ifp-if_flags IFF_POINTOPOINT) {
+ RTFREE(rt);
+ ro-ro_rt = NULL;
+ return (ENOENT);
+ }
+
if (rt-rt_flags RTF_GATEWAY)
l3addr = rt-rt_gateway;
else
You'll need to apply this by hand as gmail munges the formatting.
-Kip
Hi,
That certainly stops the panic, however data routed to the tun
interface doesn't come out the back end and data written
to the back end doesn't come out the tun interface.
[.]
Maybe this problem isn't a routing problem. I'll
look into it further and figure out if the packet is getting to the tun
driver and if so, what it thinks it's doing with it.
I wasn't correct - the data *IS* being read out of the back of
the tunnel device. When I send the ICMP, it goes into the tun
device and comes out the back end as an AF_LINK packet. ppp
silently discards this (ironically I have a comment noting
that I should really track unidentified packet counts).
I'll try to figure out what in if_tun.c is corrupting the family next...
if_tun.c is fine. The data passed from if_output() has family
AF_LINK - hence the original panic from flowtable_lookup().
So the question is why is ip_output() sending AF_LINK traffic
instead of AF_INET traffic?.
Still looking
From what I can tell, this is what is happening:
ip_output() is called with ro == NULL.
ip_output() calls flowtable_lookup() with a zeroed 'ro'.
flowtable_lookup() calls ft-ft_rtalloc() (really rtalloc1_fib()) to
initialise 'ro' and ends up with ro-ro_rt-rt_gateway-sa_family
set to AF_LINK.
Your original patch frees ro-ro_rt and fails before calling
llentry_update() with ro-ro_rt-rt_gateway-sa_family !=
AF_INET.
Now, when flowtable_lookup() fails, ro-ro_rt is NULL and
ip_output()s 'dst' gets set up with family AF_INET. Unfortunately,
right after this, after checking for IP_SENDONES, IP_ROUTETOIF
and IN_MULTICAST, the ip_output() code decides to call
in_rtalloc_ign() (which eventually just calls rtalloc1_fib()) to
initialise ro-ro_rt and then sets dst to be ro-ro_rt-rt_gateway
-- which is *still* an AF_LINK address!
Finally ip_output() calls ifp-if_output() (really tunoutput()) with
dst's family set to AF_LINK, tunoutput() queues it to the tun
character device, ppp reads it and drops it on the floor 'cos it
doesn't know what to do with AF_LINK.
The tun driver is more or less the same as the -stable version,
so it seems that ip_output() is to blame. The only relevant part
that seems substantially different is rtalloc1_fib(), so right now
I'm guessing that the RTF_CLONING code in -stable always
clones the route with a gw family of AF_INET and expectations
are met after that.
I'll look some more on the weekend...
On Fri, Aug 21, 2009 at 16:43, Brian Somersbr...@freebsd.org wrote:
Hi,
I've been working on a fix to address an issue that came up with
our update of openssh-5. The issue is that openssh-5 now uses
pipe() to create stdin/stdout channels between sshd and the server
side program where it used to use socketpair(). Because it uses
pipe(), stdin is no longer bi-directional and cannot be used for both
input and output by a child process. This breaks the use of ssh
as a tunnel with ppp on either end (set device !ssh -e none host
ppp -direct label)
I talked with des@ for a while and then with the openssh folks and
have not been able to resolve the issues in openssh that made them
choose to enforce the use of pipe() over socketpair(). I now have a
patch to ppp that makes ppp detect that it's connected via pipe() and
causes it to use stdin for input and stdout for output (usually it
expects
just one descriptor). Although I'm happy with the patch and planned
on
requesting permission to commit, I've bumped into a show-stopper
that seems unrelated, so I thought I'd ask here if anyone has seen
this or has any suggestions as to what the problem might be.
The issue
I'm seeing a panic when I send traffic through a ppp link:
panic string is: sin_family 18
Stack trace starts
Re: kernel panics in in_lltable_lookup (with INVARIANTS)
On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers br...@freebsd.org wrote:
On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy km...@freebsd.org wrote:
Try this:
Index: sys/net/flowtable.c
===
--- sys/net/flowtable.c (revision 196382)
+++ sys/net/flowtable.c (working copy)
@@ -688,6 +688,12 @@
struct rtentry *rt = ro-ro_rt;
struct ifnet *ifp = rt-rt_ifp;
+ if (ifp-if_flags IFF_POINTOPOINT) {
+ RTFREE(rt);
+ ro-ro_rt = NULL;
+ return (ENOENT);
+ }
+
if (rt-rt_flags RTF_GATEWAY)
l3addr = rt-rt_gateway;
else
You'll need to apply this by hand as gmail munges the formatting.
-Kip
Hi,
That certainly stops the panic, however data routed to the tun
interface doesn't come out the back end and data written
to the back end doesn't come out the tun interface.
[.]
Maybe this problem isn't a routing problem. I'll
look into it further and figure out if the packet is getting to the tun
driver and if so, what it thinks it's doing with it.
I wasn't correct - the data *IS* being read out of the back of
the tunnel device. When I send the ICMP, it goes into the tun
device and comes out the back end as an AF_LINK packet. ppp
silently discards this (ironically I have a comment noting
that I should really track unidentified packet counts).
I'll try to figure out what in if_tun.c is corrupting the family next...
Cheers.
On Fri, Aug 21, 2009 at 16:43, Brian Somersbr...@freebsd.org wrote:
Hi,
I've been working on a fix to address an issue that came up with
our update of openssh-5. The issue is that openssh-5 now uses
pipe() to create stdin/stdout channels between sshd and the server
side program where it used to use socketpair(). Because it uses
pipe(), stdin is no longer bi-directional and cannot be used for both
input and output by a child process. This breaks the use of ssh
as a tunnel with ppp on either end (set device !ssh -e none host
ppp -direct label)
I talked with des@ for a while and then with the openssh folks and
have not been able to resolve the issues in openssh that made them
choose to enforce the use of pipe() over socketpair(). I now have a
patch to ppp that makes ppp detect that it's connected via pipe() and
causes it to use stdin for input and stdout for output (usually it expects
just one descriptor). Although I'm happy with the patch and planned on
requesting permission to commit, I've bumped into a show-stopper
that seems unrelated, so I thought I'd ask here if anyone has seen
this or has any suggestions as to what the problem might be.
The issue
I'm seeing a panic when I send traffic through a ppp link:
panic string is: sin_family 18
Stack trace starts:
in_lltable_lookup()
llentry_update()
flowtable_lookup()
ip_output()
The panic is due to a KASSERT in in_lltable_lookup() that expects the
sockaddr to be AF_INET. Number 18 is AF_LINK.
AFAICT this is happening while setting up a temporary route for the
first outbound packet. I haven't been able to do much investigation
yet due to other patches in my tree that seem to have broken all my
kernel symbols, but once I get a clean rebuild I should be back in
business.
If anyone has any suggestions, I'm all ears!
Cheers.
--
Brian Somers br...@awfulhak.org
Don't _EVER_ lose your sense of humour ! br...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
kernel panics in in_lltable_lookup (with INVARIANTS)
Hi, I've been working on a fix to address an issue that came up with our update of openssh-5. The issue is that openssh-5 now uses pipe() to create stdin/stdout channels between sshd and the server side program where it used to use socketpair(). Because it uses pipe(), stdin is no longer bi-directional and cannot be used for both input and output by a child process. This breaks the use of ssh as a tunnel with ppp on either end (set device !ssh -e none host ppp -direct label) I talked with des@ for a while and then with the openssh folks and have not been able to resolve the issues in openssh that made them choose to enforce the use of pipe() over socketpair(). I now have a patch to ppp that makes ppp detect that it's connected via pipe() and causes it to use stdin for input and stdout for output (usually it expects just one descriptor). Although I'm happy with the patch and planned on requesting permission to commit, I've bumped into a show-stopper that seems unrelated, so I thought I'd ask here if anyone has seen this or has any suggestions as to what the problem might be. The issue I'm seeing a panic when I send traffic through a ppp link: panic string is: sin_family 18 Stack trace starts: in_lltable_lookup() llentry_update() flowtable_lookup() ip_output() The panic is due to a KASSERT in in_lltable_lookup() that expects the sockaddr to be AF_INET. Number 18 is AF_LINK. AFAICT this is happening while setting up a temporary route for the first outbound packet. I haven't been able to do much investigation yet due to other patches in my tree that seem to have broken all my kernel symbols, but once I get a clean rebuild I should be back in business. If anyone has any suggestions, I'm all ears! Cheers. -- Brian Somers br...@awfulhak.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kernel panics in in_lltable_lookup (with INVARIANTS)
to a KASSERT in in_lltable_lookup() that expects the sockaddr to be AF_INET. Number 18 is AF_LINK. AFAICT this is happening while setting up a temporary route for the first outbound packet. I haven't been able to do much investigation yet due to other patches in my tree that seem to have broken all my kernel symbols, but once I get a clean rebuild I should be back in business. If anyone has any suggestions, I'm all ears! Cheers. -- Brian Somers br...@awfulhak.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to signal a time zone change?
On Fri, 7 Aug 2009 15:08:16 -0700 Peter Steele
pste...@webmail.maxiscale.com wrote:
What's the value of the TZ environment variable for the C apps? You may
need to have them read the new value from somewhere, and then rerun
tzset().
The default value of the TZ environment variable is null. I just tried
passing the explicitly time zone value to the C app and setting TZ to
that value and that seemed to work. I would think that that I should be
able to retrieve that value from /etc/localtime as the docs imply. Guess
not. If I have to pass the time zone to the C app, then I guess that's
what I'll do...
This doesn't work because of two bugs in localtime.c. The first is what
you're hitting where tzset() calls tzset_basic() which calls tzsetwall_basic()
which says:
if (lcl_is_set 0) {
if (!rdlocked)
_RWLOCK_UNLOCK(lcl_rwlock);
return;
}
If you were to have your own TZ setting and wanted to modify the
file referred to by that, you'd bump into this bug in tzset_basic():
if (lcl_is_set 0 strcmp(lcl_TZname, name) == 0) {
if (!rdlocked)
_RWLOCK_UNLOCK(lcl_rwlock);
return;
}
Roughly translated, localtime.c goes out of its way to never re-read the
same zone file twice in a row. This is just a mistake.
As you discovered, altering TZ before calling tzset() is the best way to
make it work right now. If you really want to ensure that you're reading
/etc/localtime, this bit of hackery works too:
putenv(TZ=/dev/null);
tzset();
unsetenv(TZ);
tzset();
If you raise a PR and let me know the number, I'd be happy to fix this.
--
Brian Somers br...@awfulhak.org
Don't _EVER_ lose your sense of humour ! br...@freebsd.org
signature.asc
Description: PGP signature
Re: can we afford an extra column in iostat?
On Tue, 14 Jul 2009 07:23:12 +0300, Giorgos Keramidas keram...@freebsd.org wrote: While converting my laptop's main disk to zfs, I noticed iostat output like this (bits copied from here and there): | keram...@kobe:/home/keramida$ iostat -w3 ad0 da0 | tty ad0 da0 cpu | tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id |5 2119 36.29 56 2.00 54.95 7 0.35 3 0 8 0 89 |0 9478 10.90 290 3.09 57.22 12 0.67 42 0 43 0 15 |012595 1.72 213 0.36 21.36 80 1.66 48 0 48 0 4 |050042 4.56 715 3.19 11.44 164 1.83 29 0 50 1 20 | 11529568 7.34 443 3.17 16.97 165 2.74 31 0 53 0 16 [.] | $ ./iostat -w2 | tty ad0 md0 da0 cpu | tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id |7 2570 32.92 62 1.98 6.46 0 0.00 43.44 10 0.41 4 0 9 0 87 |0 36506 0.99 507 0.49 0.00 0 0.00 20.13 155 3.04 34 0 56 1 9 |0 16695 0.83 226 0.18 0.00 0 0.00 26.16 97 2.48 35 0 56 0 9 |0 24158 10.63 428 4.45 0.00 0 0.00 14.44 137 1.93 32 0 51 0 17 | ^C The patch that changes this is quite small: This should be fixed. Ironically, the only people that usually have problems with fixes like this are people that have seen the fields merge and have adjusted some script to understand column widths! -- Brian Somers br...@awfulhak.org Don't _EVER_ lose your sense of humour !br...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
make {,re}installkernel{,.debug}
(DEBUG_FLAGS) !defined(INSTALL_NODEBUG)
- ${INSTALL} -o ${KMODOWN} -g ${KMODGRP} -m ${KMODMODE} \
- ${_INSTALLFLAGS} ${PROG}.symbols ${DESTDIR}${KMODDIR}
-.endif
.include bsd.links.mk
@@ -290,6 +290,16 @@ _kldxref:
.endif # !target(install)
+.if !target(install.debug)
+install.debug:
+.if defined(DEBUG_FLAGS)
+ ${INSTALL} -o ${KMODOWN} -g ${KMODGRP} -m ${KMODMODE} \
+ ${_INSTALLFLAGS} ${PROG}.symbols ${DESTDIR}${KMODDIR}
+.endif
+.endif # !target(install.debug)
+
+install.debug: install
+
.if !target(load)
load: ${PROG}
${KMODLOAD} -v ${.OBJDIR}/${PROG}
Index: UPDATING
===
--- UPDATING(revision 195527)
+++ UPDATING(working copy)
@@ -22,6 +22,11 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 8.x IS SLOW:
to maximize performance. (To disable malloc debugging, run
ln -s aj /etc/malloc.conf.)
+20090709:
+ The use of INSTALL_NODEBUG has been deprecated and symbol files
+ are no longer installed by default. To install kernel and
+ module symbol files, use the {,re}installkernel.debug target.
+
20090630:
The NFS_LEGACYRPC option has been removed along with the old
kernel RPC implementation that this option selected. Kernel
Index: Makefile
===
--- Makefile(revision 195527)
+++ Makefile(working copy)
@@ -11,9 +11,9 @@
# world - buildworld + installworld, no kernel.
# buildkernel - Rebuild the kernel and the kernel-modules.
# installkernel - Install the kernel and the kernel-modules.
-# installkernel.debug
+# installkernel.debug - Also install kernel and module symbols.
# reinstallkernel - Reinstall the kernel and the kernel-modules.
-# reinstallkernel.debug
+# reinstallkernel.debug - Also reinstall kernel and module symbols.
# kernel - buildkernel + installkernel.
# doxygen - Build API documentation of the kernel, needs doxygen.
# update - Convenient way to update your source tree (cvs).
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 195527)
+++ Makefile.inc1 (working copy)
@@ -682,6 +682,9 @@ distrib-dirs distribution:
# for building kernels and only the first of these is designated
# as the one being installed.
#
+# If your kernel is built with DEBUG set, installkernel.debug
+# will additionally install kernel and module symbols.
+#
# Note that we have to use TARGET instead of TARGET_ARCH when
# we're in kernel-land. Since only TARGET_ARCH is (expected) to
# be set to cross-build, we have to make sure TARGET is set
Index: share/mk/bsd.subdir.mk
===
--- share/mk/bsd.subdir.mk (revision 195516)
+++ share/mk/bsd.subdir.mk (working copy)
@@ -67,7 +67,7 @@ ${SUBDIR}: .PHONY
.for __target in all all-man checkdpadd clean cleandepend cleandir \
depend distribute lint maninstall manlint \
-obj objlink realinstall regress tags \
+obj objlink realinstall install.debug regress tags \
${SUBDIR_TARGETS}
${__target}: _SUBDIR
.endfor
--
Brian Somers br...@awfulhak.org
Don't _EVER_ lose your sense of humour ! br...@freebsd.org
signature.asc
Description: PGP signature
Re: My PPP timer PR [nag]
On Fri, 11 May 2007 17:14:16 +0100 (BST) Robert Watson [EMAIL PROTECTED] wrote: On Thu, 10 May 2007, Sergey Zaharchenko wrote: bin/102747 has been sitting there for about 8 months, with no activity since it was assigned to brian@, all my mail to whom bounces [CC'd just in case]. The patch attached in the PR has been working for me since, so it not being fixed in the main tree isn't a problem with me. I just thought someone would benefit from it being committed... In general, I would suggest sending this sort of thing to current@ and/or net@, but not [EMAIL PROTECTED] I'll have a look at it RSN - or at BSDCan next week at the latest. -- Brian Somers [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ![EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: read a file from a driver
There's an example of how to do this in the ``digi'' driver. It loads it's firmware module on-the-fly (if it can) and dumps it afterwards. As you can see, this saves a bunch of runtime space (digi is the base driver, digi_* are the firmware modules): $ ls -l /boot/kernel/digi* -r-xr-xr-x 1 root wheel 36911 Mar 29 00:48 /boot/kernel/digi.ko -r-xr-xr-x 1 root wheel 17800 Mar 29 00:48 /boot/kernel/digi_CX.ko -r-xr-xr-x 1 root wheel 69548 Mar 29 00:48 /boot/kernel/digi_CX_PCI.ko -r-xr-xr-x 1 root wheel 68764 Mar 29 00:48 /boot/kernel/digi_EPCX.ko -r-xr-xr-x 1 root wheel 70336 Mar 29 00:48 /boot/kernel/digi_EPCX_PCI.ko -r-xr-xr-x 1 root wheel 11400 Mar 29 00:48 /boot/kernel/digi_Xe.ko -r-xr-xr-x 1 root wheel 72852 Mar 29 00:48 /boot/kernel/digi_Xem.ko -r-xr-xr-x 1 root wheel 73608 Mar 29 00:48 /boot/kernel/digi_Xr.ko Unfortunately, if you want to load digi from loader.conf, you have to explicitly load the firmware module(s) too as the module load function is called before the filesystem is available. FWIW, Solaris has a crude interface that will allow you to open and getc/putc a file. It's smart enough to know that it should talk to the boot prom if roodev isn't yet set. I believe it was required for Solaris' drivers to be able to read their .conf files at boot time, and was sufficient to allow access to other files in the software I was writing. generally the answer is You can't do that BUT you could make a loadable module with the firmware, and load both the module and the driver before booting from the boot blocks.. then you can unload the firmware module after booting (or whenever) On Wed, 3 Apr 2002, Kreider, Carl wrote: I am working on an embedded project running FreeBSD, and my driver for our custom card needs to load an FPGA with code. I know I can compile the code in as data, but for ease of development, I would rather fetch the FPGA code from a file. With a driver in kernel space. Really. Can it be done? If so, how? open() and read() are obviously in libc which rules them out. Do I have to write my own in assembler? -- Carl Kreider Wind River Doctor Design Services 700 E Beardsley Suite 14A Elkhart Indiana 46514 219-206-8050 x104 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] = On two occasions I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. -- Charles Babbage = -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 'rm' incompatibility with Posix.2
Bogdan TARU [EMAIL PROTECTED] writes: On 10 Apr 2002, Dag-Erling Smorgrav wrote: In my humble opinion, Solaris (and every other *nix) is broken in this respect, and *BSD is correct. Except for OpenBDS. No NetBDS machine available, maybe some of you could try it on one as well? I don't know of any OpenBDS or NetBDS, but NetBSD has the same semantics as FreeBSD: des@rc4 ~% mkdir foo des@rc4 ~% touch foo/bar des@rc4 ~% ln -s foo baz des@rc4 ~% ls -l baz lrwxr-xr-x 1 des des 3 Apr 10 16:41 baz@ - foo des@rc4 ~% ls -l baz/ total 0 -rw-r--r-- 1 des des 0 Apr 10 16:41 bar OpenBSD is the same. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: Jul 30 changes to ppp break my Telstra ADSL PPPoE connection]
Brian Somers wrote:
Hi,
Thanks for your report. Would you be able to grab me logs of the
connection that doesn't work (the latest ppp) and the one that works
(the pre-July 30 one) with the following set:
set log tun chat lcp ipcp
It may be possible to fix the problem by changing your ``set mru''
and ``set mtu'' lines to
set mru max 1454
set mtu max 1454
but, even if this is successful, I'd be interested in the logs.
It may also be worth trying the latest version of ppp from my web
site (http://www.Awfulak.org/~brian) - just in case it's something
that I've already fixed but have forgotten to MFC. If that's the
case, then I should be able to find the bogus code more easily.
I am having great difficulty getting logs. I noticed the last time I had ppp log
data was November 20th. But this is what I have.
/etc/syslog.conf:
!ppp
*.* /var/log/ppp.log
/var/log/ppp.log:
Dec 5 08:02:26 server ppp[198]: tun0: LCP: deflink: RecvEchoRequest(2) state =
Opened
Dec 5 08:02:26 server ppp[198]: tun0: LCP: deflink: SendEchoReply(2) state = Opened
This looks ok. Can you show me the logs from when the connection is
established in each case ?
Cheers.
jhousley@server:~ {13} pppctl -p xx 3000 show log
Log: Chat IPCP LCP Tun Warning Error Alert
Local: Warning Error Alert
I am getting this with both RELENG_4_3 ppp and RELENG_4 ppp. Yes syslogd is running
as syslogd -s -s If I turn on tcp/ip or debug I get lots of information in the log
files. Is it possible that some of the log levels were broken. I will try the
latest verson from (http://www.Awfulak.org/~brian) is see if that logs properly
Jim
--
/\ ASCII Ribbon Campaign .
\ / - NO HTML/RTF in e-mail .
X - NO Word docs in e-mail .
/ \ -
[EMAIL PROTECTED] http://www.FreeBSD.org The Power to Serve
[EMAIL PROTECTED] http://www.TheHousleys.net
[EMAIL PROTECTED] http://www.SimTel.Net
-
Your mouse has moved.
Windows NT must be restarted for the change to take effect!
Reboot now? [OK]
--
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
http://www.freebsd-services.com/brian@[uk.]FreeBSD.org
Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: Jul 30 changes to ppp break my Telstra ADSL PPPoE connection]
Hi, Thanks for your report. Would you be able to grab me logs of the connection that doesn't work (the latest ppp) and the one that works (the pre-July 30 one) with the following set: set log tun chat lcp ipcp It may be possible to fix the problem by changing your ``set mru'' and ``set mtu'' lines to set mru max 1454 set mtu max 1454 but, even if this is successful, I'd be interested in the logs. It may also be worth trying the latest version of ppp from my web site (http://www.Awfulak.org/~brian) - just in case it's something that I've already fixed but have forgotten to MFC. If that's the case, then I should be able to find the bogus code more easily. Thanks. Original Message From: Greg Lane [EMAIL PROTECTED] Subject: Jul 30 changes to ppp break my Telstra ADSL PPPoE connection To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] G'day all, I have a problem with PPPoE over Telstra ADSL (Australia). A full description of the problem can be found in freebsd-questions (see [EMAIL PROTECTED] dated Nov 30) with the subject: ADSL PPPoE (Telstra Aust.) began to hang between 4.3- and 4.4-RELEASE The short of it is that at some point during my cvsup history certain types of traffic would hang, specifically most web traffic and certain types of ssh (e.g. ls -l of a long directory). This was reminiscent of the MTU/MRU problems at the beginning of the year. I backdated to 4.3-RELEASE which worked and I forgot about it until recently when I decided to change my gateway machine. I have now chased it up in earnest by going back through various dated cvsup's and making the world. On July 30th there were some changes to src/usr.sbin/ppp that break ppp and cause this problem. Strangely enough the changes were related to MRU's :- !! I can reliably make my DSL connection work on three different machines using four different network cards (ed, de, vr, rl) with source dated Jul 30 12:01am, and reliably break it with anything after Jul 31 12:01am. The changes made to ppp on that day were to: src/usr.sbin/ppp/command.c src/usr.sbin/ppp/lpc.c src/usr.sbin/ppp/nat_cmd.c src/usr.sbin/ppp/nat_cmd.h src/usr.sbin/ppp/ppp.8 The most likely problem is lpc.c because 1) it looks the most complicated(!!) and 2) it is supposed to: MFC: Handle peer REQ/NAKs of 1500 byte MRUs when we have no preference The other diffs were small and were to implement two issues: MFC: If the peer REJects our MRU REQ, stop REQing it -- *EVEN* if we're doing PPPoE and the default MRU is therefore too big. MFC: Actually add the ``nat proto'' command I'm afraid my lack of knowledge stops me going on from here. My ppp.conf is below and I start ppp with ppp -ddial -nat -quiet bigpond Can anyone see the problem and suggest further detective work I can perform or even better, a fix or workaround? Cheers, Greg P.S. I have cross-posted to questions since the thread started there and hackers since I believe I have narrowed down the problem and it is technical. I hope this is OK. Please confine your reply to whatever list you feel is appropriate, I am subscribed to both. --- default: #Only enable logging for troubleshooting #set log CBCP CCP Chat Connect Command IPCP tun Phase Warning Debug LCP sync set device PPPoE:rl0:bigpond set speed sync set mru 1454 set mtu 1454 set ctsrts off enable lqr add default HISADDR set timeout 0 set redial 7 0 set socket /var/run/pppsocket * #Network Address Translation (NAT) nat enable yes nat log yes #nat same_ports yes nat unregistered_only yes #enable dns # this disabled since the box now runs its own dns bigpond: set authname *** set authkey *** --- -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Checking changes to listening ports in /etc/security
From: Brian Somers [EMAIL PROTECTED]
Subject: Re: Checking changes to listening ports in /etc/security
Date: Fri, Sep 14, 2001 at 12:18:43PM +0100
I think the attached patch makes things slightly better. We only run
sockstat once, and remove the trailing whitespace that sockstat emits
(making the diff lines look better when viewed on an 80 column
screen).
Ahem, that's what happens when one works in 132 column modes.
Yes, trailing spaces are better removed.
Could you look these over ? If you're happy with this I can commit
it.
Looks great to me. I tested it with the usual four runs of
periodic/daily/450.status-security that I used for my versions.
It works great :)
I found a problem... if you reboot a machine, lots of diffs come up
because of the PID column. I've got a version running locally that
dykes out the PID stuff from the report. It also displays the header
line above the diff output for a bit of context. If it works ok over
the next few days I'll commit it.
I've attached the patch FYI.
-giorgos
--
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
http://www.freebsd-services.com/brian@[uk.]FreeBSD.org
Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org
Index: security
===
RCS file: /home/ncvs/src/etc/security,v
retrieving revision 1.55
diff -u -r1.55 security
--- security4 Jul 2001 12:49:17 - 1.55
+++ security17 Sep 2001 00:37:01 -
@@ -128,6 +128,31 @@
tee /dev/stderr | wc -l)
[ $n -gt 0 -a $rc -lt 1 ] rc=1
+# Show changes in listening tcp and udp ports:
+#
+sockstat -l46 | {
+ read line
+ echo ${line}
+ sed -e /^USER/d -e /comsat/d -e '/^[ ]*$/d' | sort +5
+} | sed -e 's/[ ][ ]*$//' -e 's/\(..\)./\1/' ${TMP}
+
+if [ ! -f ${LOG}/sockstat.today ]; then
+ [ ${rc} -lt 1 ] rc=1
+ separator
+ echo ${host} changes in listening ports:
+ diff -b /dev/null ${TMP}
+ touch ${LOG}/sockstat.yesterday || rc=3
+ mv ${TMP} ${LOG}/sockstat.today || rc=3
+elif ! cmp ${LOG}/sockstat.today ${TMP} /dev/null 21; then
+ [ ${rc} -lt 1 ] rc=1
+ separator
+ echo ${host} changes in listening ports:
+ sed '1{ s/^/ /; q; }' ${TMP}
+ diff -b ${LOG}/sockstat.today ${TMP}
+ mv ${LOG}/sockstat.today ${LOG}/sockstat.yesterday || rc=3
+ mv ${TMP} ${LOG}/sockstat.today || rc=3
+fi
+
# Show denied packets
#
if ipfw -a l 2/dev/null | egrep deny|reset|unreach ${TMP}; then
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Checking changes to listening ports in /etc/security
From: Brian Somers [EMAIL PROTECTED]
Subject: Re: Checking changes to listening ports in /etc/security
Date: Thu, Sep 13, 2001 at 10:25:02PM +0100
I like this idea. I think It would be worth making it diff against
/dev/null when netstat.today doesn't exist, so that the first time
this is run on a given machine, you get to see all the ports that are
open.
Done. I duplicated the code of the second if[] since I could not easily come
up with a version that does not use some kind of shell variable weirdness
and still work the same way. I prefer to keep this clean and easy to
understand. The attached patch makes /dev/null the first argument of diff
when sockstat.today does not exist.
[.]
Hi,
I think the attached patch makes things slightly better. We only run
sockstat once, and remove the trailing whitespace that sockstat emits
(making the diff lines look better when viewed on an 80 column
screen).
Could you look these over ? If you're happy with this I can commit
it.
Cheers.
--
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
http://www.freebsd-services.com/brian@[uk.]FreeBSD.org
Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org
Index: security
===
RCS file: /home/ncvs/src/etc/security,v
retrieving revision 1.55
diff -u -r1.55 security
--- security4 Jul 2001 12:49:17 - 1.55
+++ security14 Sep 2001 11:12:09 -
@@ -128,6 +128,30 @@
tee /dev/stderr | wc -l)
[ $n -gt 0 -a $rc -lt 1 ] rc=1
+# Show changes in listening tcp and udp ports:
+#
+sockstat -l46 | {
+ read line
+ echo $line
+ sed -e /^USER/d -e /comsat/d -e '/^[ ]*$/d' | sort +5
+} | sed 's/[][ ]*$//' ${TMP}
+
+if [ ! -f $LOG/sockstat.today ]; then
+ [ $rc -lt 1 ] rc=1
+ separator
+ echo $host changes in listening ports:
+ diff -b /dev/null $TMP
+ touch $LOG/sockstat.yesterday || rc=3
+ mv $TMP $LOG/sockstat.today || rc=3
+elif ! cmp $LOG/sockstat.today $TMP /dev/null 21; then
+ [ $rc -lt 1 ] rc=1
+ separator
+ echo $host changes in listening ports:
+ diff -b $LOG/sockstat.today $TMP
+ mv $LOG/sockstat.today $LOG/sockstat.yesterday || rc=3
+ mv $TMP $LOG/sockstat.today || rc=3
+fi
+
# Show denied packets
#
if ipfw -a l 2/dev/null | egrep deny|reset|unreach ${TMP}; then
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Checking changes to listening ports in /etc/security
I've been adding an extra check in my local version of /etc/security for quite
some time now. All it does is use 'netstat' to grab a list of the listening
tcp and udp ports of my machine and save it to /var/log/netstat.today
(and /var/log/netstat.yesterday). This way, when some service starts
and listens on a new port the next run of /etc/security will log the
fact in the usual stuff sent to root by mail. I tested this running
/etc/periodic/daily/450.security twice, and running a local IRC daemon between
the two runs. The output that is added to the message root receives looks
like the following:
[.]
I like this idea. I think It would be worth making it diff against
/dev/null when netstat.today doesn't exist, so that the first time
this is run on a given machine, you get to see all the ports that are
open.
[.]
+[ -n $ignore ] cmd=egrep -v ${ignore#|} || cmd=cat
[.]
I think this like is bogus. In fact, it looks like the
$daily_status_security_noamd periodic.conf tunable is broken.
Oops ! I'll fix it after your changes go in.
--
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
http://www.freebsd-services.com/brian@[uk.]FreeBSD.org
Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Driver structures alignment
Hi there, Is there a single blessed way to define packed structures for use in drivers? I suspect that using #pragma pack(1) will lead to alignment errors in non-Intel architectures. gcc deals with it, certainly on alpha anyway. However, I don't think anyone would ever bless using packed structures as it hurts memory transfers. I prefer the fix-it-up-when-I-need-it-packed approach :*) -- Yar -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: For review: Patch to ps(1) old-style option parsing.
This is pretty low-priority and I don't think it needs to be MFC'd for the 4.4 release, but there is a small error in ps's old-style option handling. An outstanding example of this is when one runs `ps Uroot': This has irritated me in the past too :*) I've applied your patch to -current. Thanks. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: a little O/T, but D.V.D. drivesfreeBSD
,[ On Thu, Aug 02, at 05:57PM, Julian Elischer wrote: ]-- | anyone had success watching a dvd? `[ End Quote ]--- ok, first and foremost, please, anyone else replying, reply to the list and not to me and please dont cc me, i am on the list. (i have to, i got a LOT of replies far after my answer was achieved last time) anyway, vlc is what you want, it works decently if you have a good video card, it simply reboots my -current laptop, so your milleage may vary, but there are numerous reports of successful usage. good luck. --gabe This program doesn't seem to work very well at all. It seems to create a thread and set p_vout to NULL on line 95 of vlc-0.2.81/src/video_decoder/vpar_synchro.c, then goes and dereferences it on line 228 of vlc-0.2.81/src/video_decoder/vpar_synchro.c. If anyone's interested in committing it as a port, you can find the necessary files at ftp://ftp.Awfulhak.org/pub/vlc-port. -- It's not brave if you're not scared. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: portmap_enable vs. rpcbind_enable
In message [EMAIL PROTECTED] Dima Dorfman writes: : Does anybody know (remember?) why portmap_enable (the rc.conf knob) : wasn't renamed to rpcbind_enable when portmap became rpcbind? It : seems odd to have a knob called portmap_enable that actually starts : something called rpcbind (not to mention violating POLA). Because we didn't want to break old people's config files. Also, the rpcbind rename was stupid and there were people at the time that had hoped it be renamed portmap since that was a bigger pola :-) Are you referring to grog bde only ? Warner -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: portmap_enable vs. rpcbind_enable
In message [EMAIL PROTECTED] Brian Somers writes: : In message [EMAIL PROTECTED] Dima Dorfman writes: : : Does anybody know (remember?) why portmap_enable (the rc.conf knob) : : wasn't renamed to rpcbind_enable when portmap became rpcbind? It : : seems odd to have a knob called portmap_enable that actually starts : : something called rpcbind (not to mention violating POLA). : : Because we didn't want to break old people's config files. Also, the ^^ : rpcbind rename was stupid and there were people at the time that had : hoped it be renamed portmap since that was a bigger pola :-) : : Are you referring to grog bde only ? There were a fair number of people that wanted the name to remain the same... I want it to remaint he same, but I don't care enough to fight. I was actually making a smart arse comment about your wording :*) Warner -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why install -C include files?
On Wed, 25 Jul 2001 08:58:02 CST, Warner Losh wrote: The reason I'd like to see it isn't so that make world kills things automatically, but so that I could kill them (or at least find out what should be killed) on systems that had FreeBSD 1.0 installed on them, then upgraded, disk cloned, etc. That's exactly what I'm talking about. :-) Every now and then, rather than doing ``make installworld'', do: # cd /usr # mv share share.not # mv include include.not # mv libdata libdata.not # cd src # make -m /usr/src/share/mk installworld # cd .. # rm -fr share.not include.not libdata.not This keeps things reasonably clean. Ciao, Sheldon. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A full source-tour somewhere?
On Mon, Jul 23, 2001 at 12:56:04AM -0700, Julian Elischer wrote: Julian Elischer wrote: Dima Dorfman wrote: [...] * A cross reference of the FreeBSD kernel well I have the source code of course, but the second is what I'm looking for except that it stopped being updated October 2000. I'm looking for a current one. oh yeah, and that one doesn't work.. try clicking on something you want to cross reference.. I'm not shure what you exactly need. With global you can simply gtags htags in a dir and enjoy the html. You have do do it for every application kernel on their own because they share identic named functions like main() and so on. The result is nice but I wouldn't call it cross reference I think devel/cscope is reasonably good. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: interface cloning MFC
I plan to MFC the network interface cloning support and the gif modularization early next week unless someone has objections. I'd like to get it in before the code slush and since I'll be leaving for a week on the 31st, that means sometime early to mid next week to allow for any bug reports. I don't really expect any problems. Good stuff. A diff is available at: http://people.freebsd.org/~brooks/patches/gif-stable.diff You forgot: Index: LINT === RCS file: /home/ncvs/src/sys/i386/conf/Attic/LINT,v retrieving revision 1.749.2.64 diff -u -r1.749.2.64 LINT --- LINT2001/06/29 21:14:24 1.749.2.64 +++ LINT2001/07/20 19:35:42 @@ -509,7 +509,7 @@ optionsETHER_SNAP # enable Ethernet_802.2/SNAP frame # for IPv6 -pseudo-device gif 4 #IPv6 and IPv4 tunneling +pseudo-device gif #IPv6 and IPv4 tunneling pseudo-device faith 1 #for IPv6 and IPv4 translation pseudo-device stf #6to4 IPv6 over IPv4 encapsulation I'm just rebuilding the world now :) I'll let you know how I get on. Thanks for your work. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: interface cloning MFC
I plan to MFC the network interface cloning support and the gif modularization early next week unless someone has objections. I'd like to get it in before the code slush and since I'll be leaving for a week on the 31st, that means sometime early to mid next week to allow for any bug reports. I don't really expect any problems. A diff is available at: http://people.freebsd.org/~brooks/patches/gif-stable.diff apply with: cd /usr/src mkdir sys/modules/if_gif sys/modules/if_stf patch gif-stable.diff -- Brooks This works nicely on my -stale box. Thanks. One niggle though :) It's probably worth changing ``$FreeBSD: $'' to ``$FreeBSD$'' in your patched version. Without this, mergemaster assumes that the new version in /usr/src/etc is the same as the /etc version (same Ids). This caused a problem here, I fixed the problem and went to prepare a patch for you the patch file came up empty -- you already had the missing ``create'' in your patches (of course) :*D Cheers. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: mgetty+AutoPPP pointers?
There's stuff in the ppp(8) man page about this -- although I've deprecated the mgetty stuff in favour of getty which is capable of doing the same thing. Hello all, I want to configure a server machine I have at home to answer a phone line via internal modem and setup a PPP connection to the outside world (the machine is connected via broadband) for a Win98 machine being the remote caller. I've read up a little on mgetty and its use of AutoPPP to fire off pppd via various google searches. Many of the links I've brought up are reasonably decent explanations, but based around Linux setups. Does anybody have any bookmarked pointers to setting up mgetty+AutoPPP under FreeBSD -STABLE? I've dug through a few bits and I know our in-tree compilation of pppd is compiled with -DCHAPMS (which the Linux-related pointers said to make sure you used when compiling pppd) and our port of mgetty+sendfax does define -DAUTO_PPP during compilation (which was another must). Is there anything else that is needed to enable the code to DTRT? If anybody has done this sort of thing and wishes to share config files, or gotchas I would much appreciate it! Please 'cc:' me. After grepping the archives, it looks like this topic has come up a lot with varied answers but no real pointers. If somebody has pointers or sample config files, I would be happy to try and mark them up and submit them to the -doc project! -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds WCCG, CCE, (space for rent, cheap!) | | Intel Corporation MS: CH6-210 Phone: 480-554-9092 pgr: 602-868-6512 | | [EMAIL PROTECTED] http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Some questions about kernel programming
write() doesn't exist in the kernel. The simple answer is you're
going to have to read what the send() syscall does and emulate it.
First, though, you need to answer the question why do I want to do
this in the kernel?
it actually exists, however the problem is that copyin and friends
assume a seperate address space, I wonder if one could do some trick
to alias the seperate address space on top of the kernel, that should
allow copyin and friends to work on pointers into the kernel's address
space.
Solaris does this by passing a tag into it's driver calls. The tag
is given to ddi_copy{in,out}() which DTRT. When a kernel wants to
open a file, it does a layered open (lyr_open() or some such) which
results in an opaque handle with which you can do other lyr_* calls
such as lyr_ioctl(). The driver has to declare itself as being
capable of doing layered opens (via the d_flag bit of it's devsw),
meaning that it uses ddi_copy{in,out} rather than copy{in,out}.
3. How I can copy a pointer string ( character array ) from user space to
kernel space using copyin() without the following problem (I can't
pass the length the explicitly from user land):
structMySystemCall_args {
char * address;
};
int MySystemCall( p,uap)
struct proc *p;
register struct MySystemCall_args *uap;
{
char *the_address;
printf( --- uap-address : %s\n, uap-address );
printf( --- (strlen (uap-address) * sizeof(char)) : %d \n,
(strlen (uap-address) * sizeof(char)) );
copyin(uap-address, the_address, (strlen (uap-address) * sizeof(char))
);
printf(the_address: %s \n, the_address );
printf(strlen (the_address): %d \n, strlen (the_address) );
When this code run in mode kernel:
--- uap-address : 127.0.0.1
--- (strlen (uap-address) * sizeof(char)) : 9
the_address : 127.0.0.1\M-\M-Y\M-GX\M-p+\M-@@\M-_\M-*\M-@
strlen (the_address): 20
This crash the kernel later...
You've forgotten the terminating \0. Add one to the length.
You can't call kernel strlen on a userland address, you must do
something like this:
/*
* return number of characters in a userland address string
* or -1 if an illegal access occurs.
*/
int
user_strlen(uaddr)
char *uaddr;
{
int ret;
ret = -1;
do {
ch = fubyte(uaddr);
ret++;
} while (ch != 0 ch != -1);
return (ch == -1 ? -1 : ret);
}
Have a look at the digi driver in -current where I did this. The
caveat is that the kernel code looks ugly. From the driver's ioctl
routine:
case DIGIIO_IDENT:
return (copyout(sc-name, *(char **)data,
strlen(sc-name) + 1));
and from digiio.h:
#define DIGIIO_IDENT_IOW('e', 'E', char *)
and from userland (digictl.c):
char namedata[256], *name = namedata;
} else if (ioctl(fd, DIGIIO_IDENT, name) != 0) {
--
-Alfred Perlstein [[EMAIL PROTECTED]]
Ok, who wrote this damn function called '??'?
And why do my programs keep crashing in it?
--
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
http://www.freebsd-services.com/brian@[uk.]FreeBSD.org
Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Some questions about kernel programming
Have a look at the digi driver in -current where I did this. The
caveat is that the kernel code looks ugly. From the driver's ioctl
routine:
case DIGIIO_IDENT:
return (copyout(sc-name, *(char **)data,
strlen(sc-name) + 1));
and from digiio.h:
#define DIGIIO_IDENT_IOW('e', 'E', char *)
and from userland (digictl.c):
char namedata[256], *name = namedata;
} else if (ioctl(fd, DIGIIO_IDENT, name) != 0) {
Oops, we weren't talking about copyout() :*D
There's a copyinstr() function available. Would that solve the
problem ?
--
-Alfred Perlstein [[EMAIL PROTECTED]]
Ok, who wrote this damn function called '??'?
And why do my programs keep crashing in it?
[.]
--
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
http://www.freebsd-services.com/brian@[uk.]FreeBSD.org
Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Mall now BSDCentral
Poul-Henning Kamp wrote: | In message [EMAIL PROTECTED], Brian Somers writes: | | I'm not having a go at Cheapbytes. I'm just saying that their CDs | should be labeled official or unofficial based on their content. If | they want to drop the base ISO image onto a CD and sell it, then | they're as official as anybody else. | | Right, and what are you going to do about some random company | in Elbonia who labels and unapproved cd as Official ? | | One should never makes rules one can't enforce... Perhaps this labelling can be in the form of information on the FreeBSD.ORG web site that lists distributions that merit the official label. That seems to make a lot of sense. In this context, ``official'' really means ``sanctioned by the FreeBSD project''. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Mall now BSDCentral
Josef Karthauser [EMAIL PROTECTED] wrote: On Fri, Jul 06, 2001 at 02:28:18PM -0700, Kris Kennaway wrote: =20 In the past, the officially blessed CD distributor was kicking back money directly to FreeBSD; whatever happens in the future with respect to CD distribution, I think we should make sure this continues to happen in an economically sustainable way. =20 FSL, I believe, are keen to keep up this tradition also (although I can't speak for what projects they will be supporting). To qualify this (a little), we (FSL == FreeBSD Services Ltd) will be distributing a FreeBSD-4.4 DVD set. The profits will be used to fund developers (Paul Richards, Mark Murray and I to start with) initially in the form of our wages, but eventually in more diverse ways that are beneficial to the project at large. We also plan to adopt the give-free-DVDs-to-all-developers approach subject to our financial success. To give people confidence in our abilities, we gave away about 350 FreeBSD-4.3 DVDs at Usenix last week -- samples of what's to come (and proof that we can produce). http://www.FreeBSD-services.com/ has more details (please feel free to register for further updates). Richard Hodges [EMAIL PROTECTED] wrote: And as far as distribution goes, if my vote counts, I would suggest that anyone should have the right to sell (or give away) copies for whatever price they want. The more copies, the better! I fail to see why FreeBSD distribution should be guided to certain entities based on their political contributions. FSL have thought quite a bit about this -- what's acceptable as a FreeBSD release. We need some sort of balance. On one hand, we (the FreeBSD project) want to encourage distributors to produce copies of FreeBSD with added-value. On the other hand, we don't want to end up with the linux-effect. The idea of producing standard distributions on which vendors can base their projects means that we can keep control of the base system - ensuring that the evolution of different flavours of FreeBSD are based on what *we* want, not on what someone's marketing department wants. For example, a good way for a vendor to build their own flavour of FreeBSD might be to provide a ``Vendor-Desktop'' port/package that people can select from sysinstall to give them everything that the vendor wants to provide as standard, maybe even including proprietary stuff. So I think the idea of an ``official'' distribution is good, but only insofar as that implies that the distribution contains a specific base system. Anyone who mucks about with that official base system in a way that's not controlled by the user should not be allowed to call their distribution ``official''. Kris Kennaway [EMAIL PROTECTED] wrote: What's likely to happen if we let it is that a number of entities will publish verbatim copies of the officially produced ISO images, and do so at production cost + some profit margin which only feeds back into their own pockets. This means that if the larger CD distribution facilities like, say, CheapBytes could do this more cheaply than someone like, say, DaemonNews, the latter will find it very hard to compete without losing money unless they can feed off of some kind of preferred vendor status. Entities which are more friendly to the FreeBSD project (like DaemonNews) and who may want to donate a portion of the proceeds to the Foundation will have to take it out of their profit margins and will lose money relative to those that don't. In the past, the officially blessed CD distributor was kicking back money directly to FreeBSD; whatever happens in the future with respect to CD distribution, I think we should make sure this continues to happen in an economically sustainable way. I don't think we'll get away with ``favouring'' certain distributors. It's not really with the spirit of things. As Jordan has said, the kick-back contributions have always been very much appreciated, but not based on any official agreements. I personally believe that the distributors who contribute stuff back will continue to be favoured - but maybe I'm being idealistic. Ted Mittelstaedt [EMAIL PROTECTED] wrote: So, are you ready for $100-per-box FreeBSD distros? Do you think the FreeBSD userbase is? Boy, now THAT's sure an advance for the customer! I think you're over-reacting Ted. FSL are planning on selling the two-DVD set for around $40.00. We may even be putting a CD on the other side of the initial disc (that may put costs up by a few $$, but will benefit more people), but the FreeBSD community will continue to get reasonable value. The $100 vendors will just simply sink. Jordan Hubbard [EMAIL PROTECTED] wrote: Also, when Wes said the following: Specifically, we need a Product Manager who can shepherd FreeBSD through the release process, and coordinate with CD-ROM distributor(s) who are I think he perhaps wasn't clear on the fact that I'll still
Re: FreeBSD Mall now BSDCentral
On Sat, 7 Jul 2001, Brian Somers wrote: Richard Hodges [EMAIL PROTECTED] wrote: And as far as distribution goes, if my vote counts, I would suggest that anyone should have the right to sell (or give away) copies for whatever price they want. The more copies, the better! I fail to see why FreeBSD distribution should be guided to certain entities based on their political contributions. FSL have thought quite a bit about this -- what's acceptable as a FreeBSD release. We need some sort of balance. On one hand, we (the FreeBSD project) want to encourage distributors to produce copies of FreeBSD with added-value. On the other hand, we don't want to end up with the linux-effect. Really? I was hoping to see a new disto with the FreeBSD userland wrapped around a Linux kernel :-) Or was it the other way around... But as far as added-value goes, why wouldn't minimum cost be an added value to a potential customer? I think that the companies like Cheapbytes serve a social purpose in this regard. I'm not having a go at Cheapbytes. I'm just saying that their CDs should be labeled official or unofficial based on their content. If they want to drop the base ISO image onto a CD and sell it, then they're as official as anybody else. So I think the idea of an ``official'' distribution is good, but only insofar as that implies that the distribution contains a specific base system. Anyone who mucks about with that official base system in a way that's not controlled by the user should not be allowed to call their distribution ``official''. Sure, no argument there. Taking Wes' suggestion, maybe there is an opportunity in the official distribution distinction. How about a certificate of authenticity which costs the vendors $1 or $2 (or whatever), and shows the customer that their choice of vendors helped FreeBSD financially. Incidentally, this certificate might also be a selling point for those twisted individuals that just don't understand free software :-) Companies that sell CDs shouldn't necessarily be limited in the ways that they can give back to the project. If a company (WRS for example) are forking out lots of money to the FreeBSD project already, why should they have to now send money to the foundation ? Besides, our software is free, it's not shareware. Thanks for the info, -Richard --- Richard Hodges | Matriplex, inc. Product Manager | 769 Basque Way [EMAIL PROTECTED] | Carson City, NV 89706 775-886-6477| www.matriplex.com -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Linux Applications Over PPP
Brian Somers wrote: The only strange occurrence I've seen that sounds even vaguely similar is that if you leave out a nameserver line in /compat/linux/etc/hosts, it *doesn't* default to 127.1. Try adding a nameserver line (if you haven't already got one). Thanks for the suggestion, but it has still not solved the problem. In fact there wasn't even a /compat/linux/etc/hosts file, so I created one, containing the line: Oops, I meant /etc/resolv.conf... sorry. [.] John. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C++ to C translator
I requested the bug list for that ``compiler'' at one point and was
given hundreds of sheets of ``known bugs'' (several bugs per sheet).
At the time, I was looking for alternatives to g++ because of a bug
I'd come across. Needless to say, the bug in question appeared in
the cfront known-bugs documentation :)
In short, avoid cfront :o{}
The original Stroustrop ATT C++ complier called cfront was a front-end C
compiler. They may have it available at research.att.com. It's missing some
things, though, like generic container classes.
-Original Message-
From: Rayson Ho [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 03, 2001 9:45 PM
To: [EMAIL PROTECTED]
Subject: C++ to C translator
Hi,
I have written some code in C++. However, I want to run it on an old
mainframe machine, which a C++ compiler is not available.
I know that the old g++ is a C++ to C compiler. Does anyone know which
version it is? Also, anyone knows other C++ to C compilers?
Thanks,
Rayson
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
--
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
http://www.freebsd-services.com/brian@[uk.]FreeBSD.org
Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Linux Applications Over PPP
The only strange occurrence I've seen that sounds even vaguely similar is that if you leave out a nameserver line in /compat/linux/etc/hosts, it *doesn't* default to 127.1. Try adding a nameserver line (if you haven't already got one). Hi, Six million *.rpm files later, I've finally got the Linux version of Mozilla working properly. However, neither the Linux versions of Mozilla or Opera seem to be able use my PPP connection - they simply can't connect to anything, even when I'm fully connected and browsing using the FreeBSD version of Mozilla. Why is this? What setting do I need to alter to enable Linux apps to use my PPP connection? Regards, John. ppp.conf (username/password hashed out!): # # PPP Sample Configuration File # Originally written by Toshiharu OHNO # Simplified 5/14/1999 by [EMAIL PROTECTED] # # $FreeBSD: src/etc/ppp/ppp.conf,v 1.2 1999/08/27 23:24:08 peter Exp $ # default: # # Make sure that device references the correct serial port # for your modem. (cuaa0 = COM1, cuaa1 = COM2) # set device /dev/cuaa0 set log Phase Chat LCP IPCP CCP tun command set speed 57600 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \\ AT OK-AT-OK ATE1Q0M0 OK \\dATDT\\T TIMEOUT 40 CONNECT set timeout 120 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR enable dns anytime: set phone 08089933001 set authname set authkey -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: rman wildcard question
In the gif interface cloning code I used the resource management code like Brian did in the tun cloning code to manage unit numbers. When the user requests an arbitrary unit, they get the first one available, but I'm not convinced that's what we want because that has the potential to interfere with static configurations with temporary holes in them. It seems that a more logical policy would be to allocate the largest available unit, but rman_reserve_resource doesn't seem to allow that. Is there a way to do this that I'm just not seeing? Not with rman AFAIK. Bear in mind though, starting with 0x7fff as an interface unit number will look pretty ugly when you ifconfig -a -- Brooks -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cloning network interfaces
I went ahead and nuked the auto-creation and -D flag in favor of plumb and unplumb in the patch at: http://www.one-eyed-alien.net/~brooks/FreeBSD/gif.diff This version includes a change to rc.network to plumb gif interfaces before calling gifcreate. This will still trip up users who build static gif tunnels from hosts with dynamic addresses since they can't run gifconfig yet, but we don't really have any means of supporting that in the rc files yet anyway. -- Brooks This looks good to me. I've cc'd freebsd-arch to see if anyone else wants to comment. If there are no objections, I'll test commit it in about a week. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cloning network interfaces
Ok, I've got the quick and dirty way working for testing (a nine line clone handler works great for that), but I think Brian's suggestion is probably best for a real solution especialy since it's rather easier to check for permissions before allowing creation this way. My current patch lets joe user create 2^15 gif devices by doing ls /dev/gif### 2^15 times because I didn't have a proc structure handy. The other advantage is that it should be fairly easy to backport to -stable which is where the project I'm working on this for is currently being developed. I think I'll add a to ifconfig function styled after ifmaybeload() that trys to create interfaces if the user trys to do something with them. I'm still thinking about the right way to handle creation of new, free devices, perhaps a syntax like: ifconfig gif# where ifconfig returns the interface name the way mdconfig does when you don't specify a unit. If we decied that interfaces that want to grow this way will have a /dev/if_name device that accepts the appropriate ioctl(s), that should be fairly easy to implement so it works in all cases without further hacks to ifconfig. I think it'd be better to use the solaris ``plumb'' keyword. I can't recall how it works (something like ``ifconfig gif0 plumb'' - I haven't got a Solaris machine handy here), but it seemed cleaner, making it more obvious what's being done. An ``unplumb'' keyword may be appropriate for doing the removal. -- Brooks -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cloning network interfaces
In message [EMAIL PROTECTED], Brooks Davis writes: With network devices that are also normal devices the way tun is, you do this by just implementing a dev_clone event handler so when the user attempts to open a non-existent instance it's created. The problem with gif is that there's no device in /dev to open. Since most network devices at attached to hardware this usually doesn't matter, but in this case it does. [...] How would this work anyway? Comments, thoughts, ideas? The quick and dirty way: Make a clone handler despite the fact that there is no /dev entry needed. You don't actually have to create a dev entry in the clone handler, you could just create the gif_interface. Applications would then: stat(/dev/gif345) /* Ignore error */ system(ifconfig gif345 bla bla bla); The slower but less dirty: Make a sysctl which returns an integer which is the next free gif device. The really slow and very dirty: Implement cloning in ifconfig. Maybe a reasonable alternative would be to have a /dev/if_gif device with ioctls for creating and destroying interfaces. ifconfig(8) could be taught to create (and maybe even to delete) them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: speeding up /etc/security
As you suspect, mounting nosuid makes /etc/security skip the suid checks... good for giving the security-unconscious a reason to fix their system :) I was alway quite impressed with this :) On Mon, Jun 04, 2001 at 12:07:19PM -0700, Matthew Jacob wrote: Does /etc/security take filesystem mounted with: nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect. Note: this option is worthless if a public available suid or sgid wrapper like suidperl(1) is installed on your system. into account? If so, and the filesystems have nothing on them that needs suid you could mount 'm this way Just a thought, Wilko That's an interesting question. A couple of ideas: a) I wonder of RWatson's ACL stuff could help here? b) This problem cries for a DMAPI type solution- you could have a daemon that monitors all creats/chmods and retains knowledge of the filenames for all SUID/SGID creats/chmods- this way /etc/security would simply summarize the current list and could be run any time. /etc/security takes a number of hours to run on my system. The problem is that I have some very large mounted file systems and the code to look for setuid files wants to walk through them all. I recoded the check in Perl, but it ran at about the same speed. I have considered reworking the code to do the file systems in parallel, but I thought I should ask here first. Comments? Suggestions? -r To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message ---end of quoted text--- -- | / o / / _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Powered by FreeBSD/[alpha,x86] http://www.freebsd.org -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: telnet to AF_UNIX sockets [PATCH]
: :On Wed, 23 May 2001, Matt Dillon wrote: : : Nice one! I'm going to be using this all over the place myself. : :I am missing something here. Is there a practical use for this? :) : :Jamie Many programs these days use unix-domain sockets as a rendezvous for IPC between processes. Being able to connect to such sockets for monitoring, debugging, development, etc... can be very useful. pppctl(8) does this too. -Matt -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ppp problems on 4.3-RELEASE and PPPoE
Hmm, I wonder if you can catch it again and do a ``set log local physical'' and run ``tcpdump -i XXX -e not ip'' on the interface at the same time ? A ``ping -c 1'' should then show if ppp's sending the data out, and if it is, if ng_ether is forwarding it. I'm a little concerned about the MRU of 1500 too. The peer seems broken. I have patches to fix this, but they've been paid for as part of another project so will have to wait 'till the source is released. If the ping packet goes out but nothing comes back it may indicate that the peer is hung up trying to send a 1500+8 byte packet across an Ethernet that can only handle 1500 According to Brian Somers: If pppctl is still working (ppp will talk to it), then it may be worth seeing what ``show physical'' and ``show timer'' say (is the link open, or is ppp waiting for something to happen via a timeout?). Locked again with a pppctl attached. show timer -=-=- IPCP throughput timer[0x80a37d8]: freq = 1.00s, next = 0.00s, state = running physical throughput timer[0x80af068]: freq = 1.00s, next = 0.90s, state = running hdlc timer[0x80b1d84]: freq = 60.00s, next = 22.90s, state = running -=-=- show physical -=-=- Name: deflink State: open (established) Device: PPPoE:ed0: Link Type: background Connect Count: 1 Queued Packets: 0 Phone Number:N/A Defaults: Device List: PPPoE:ed0: Characteristics: sync, cs8, no parity, CTS/RTS on CD check delay: device specific Connect time: 24:08:11 14864337 octets in, 8655370 octets out 56740 packets in, 56238 packets out overall 270 bytes/sec currently 0 bytes/sec in, 0 bytes/sec out (over the last 5 secs) peak 70148 bytes/sec on Mon May 21 20:02:16 2001 -=-=- show lcp -=-=- PPP ON keltia show lcp deflink: LCP [Opened] his side: MRU 1492, ACCMAP , PROTOCOMP off, ACFCOMP off, MAGIC 6317ffaa, MRRU 0, SHORTSEQ off, REJECT my side: MRU 1500, ACCMAP , PROTOCOMP off, ACFCOMP off, MAGIC 0c7a6a1f, MRRU 0, SHORTSEQ on, REJECT Defaults: MRU = 1492, ACCMAP = LQR period = 30s, Open Mode = active (delay 1s) FSM retry = 3s, max 5 Config REQs, 5 Term REQs Ident: Negotiation: ACFCOMP = disabled denied CHAP = disabled accepted CHAP80 =disabled accepted LANMan =disabled accepted CHAP81 =disabled accepted LQR = disabled denied PAP = disabled accepted PROTOCOMP = disabled accepted -=-=- -- 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 -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ppp problems on 4.3-RELEASE and PPPoE
According to Brian Somers: Brett Glass (cc'd) has complained about a similar problem where it seems that the ng_pppoe node is locked up. I can't reproduce the problem here though :( Does the following help you : [.] Not really - I think we need ``physical'' logs so that we can see if stuff is actually being written to the netgraph node. The ``timer'' diagnostics are too verbose to be of use here. The idea is to do the ``ping -c1'', and if everything were working, see the physical log show the packet being written to netgraph and then netgraph putting it on the wire. Nothing really interesting from 'tcpdump -n -i ed0 not ip'... As in nothing at all ? I wonder what the last ``not ip'' traffic to be written was - perhaps the netgraph node thinks it's closed. -- 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 -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ppp problems on 4.3-RELEASE and PPPoE
Hi, I think it's important to quantify what a lockup is here. If pppctl is still working (ppp will talk to it), then it may be worth seeing what ``show physical'' and ``show timer'' say (is the link open, or is ppp waiting for something to happen via a timeout?). If pppctl isn't working it's worth building with -g and trying a kill -11 (or attaching with gdb) to get a stack trace. Brett Glass (cc'd) has complained about a similar problem where it seems that the ng_pppoe node is locked up. I can't reproduce the problem here though :( According to James Housley: and I am not in Canada. I am using natd and ipfw for NAT and the firewall. The link has a static IP if it matters. Below I am attaching ppp.conf. I have watched some of the data with tcpdump on both tun0 and I'm also using ppp + ng_pppoe on a 4.3-STABLE system. My MTU is 1492. Configuration below. I'm experiencing lockups from ppp (average is one time a day). ppp stops recieving anything from the modem (Alcatel Speed Touch Home with ethernet). Any idea where it could come from? -=-=- default: set device /dev/cuaa0 set speed 115200 disable lqr deny lqr set redial 15 0 set reconnect 15 1 set accmap 0 set server +3000 adsl: set device PPPoE:ed0: set authname * set authkey * set timeout 0 set mtu 1492 set mru 1492 set speed sync disable acfcomp protocomp deny acfcomp set log Phase Chat LQM hdlc LCP IPCP CCP tun set ifaddr 0/0 0/0 add 0 0 HISADDR dial -=-=- Nothing interesting from the ppp log :-( -- 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 -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sysctl to disable reboot
That's a good point. A more sophisticated sysctl again would be one that would prevent the loading of a new keymap which enabled rebooting where the previous one did not. cons.keymap.protected perhaps? I could impliment a cons.keymap.securelevel which did: 0: Anyone can change the keymap. 1: Only root can change keys with effects like reboot, panic, ... 2: Only root can make any change to the keymap. Or would that be overkill? (The name is certainly a bit silly ;-) I would have guessed that suser()ing keymap changes would be most appropriate. After all, a keymap change survives a logout and should really only be changed with care. Having said that, a malicious user with access to the keyboard can install some quite hideous root traps (a program that says login: etc etc). David. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
How to auto-boot from an alternate disk
Hi, I have a machine with 3 IDE disks and 2 SCSI disks and I want to boot from the first SCSI disk *but* my BIOS won't boot it. How are you supposed to do this ? I've currently done # boot0cfg -v -t 10 -B -s 5 ad0 # boot0cfg -v -t 1 -B -s 5 -m 0 ad1 # boot0cfg -v -t 1 -B -s 5 -m 0 ad2 Which causes things to merrily skip across my IDE disks 'till it finds the first SCSI disk, loads /boot/loader from there, finds my kernel and then drops into a dumb ``manual mount'' prompt that makes me say ``ufs:/dev/da0s1a''. What I'd *REALLY* like is some way to just say ``default to 3:da(0,a)/boot/loader''. Any suggestions ? Ta. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ppp problems on 4.3-RELEASE and PPPoE
Try reducing the interface MTU further. It's possible that there's a misconfigured router between you and the sites *and* a part of the route has an mtu of less than 1492. ``set mtu 1480'' or ``set mtu 1460'' may work. I have been having problems with the the newer Windows machines, 2000 Me, not being able to access some websites. I have had to manually edit the registry to change the MTU. This should not be needed, because I am running 4.3-RELEASE which has had the tcpmssfixup feature for a while. It is enabled. Unfortunately this maching is in an office in Canada, and I am not in Canada. I am using natd and ipfw for NAT and the firewall. The link has a static IP if it matters. Below I am attaching ppp.conf. I have watched some of the data with tcpdump on both tun0 and ed0, but I am not sure what to look for. Suggestion on how to proceed. Jim ppp.conf default: ident user-ppp VERSION (built COMPILATIONDATE) # Ensure that device references the correct serial port # for your modem. (cuaa0 = COM1, cuaa1 = COM2) # set device /dev/cuaa1 set log Phase Chat LCP IPCP CCP tun command set speed 115200 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ \\ AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 set timeout 180# 3 minute idle timer (the default) add default HISADDR# Add a (sticky) default route enable dns # request DNS info (for resolv.conf) magma: ident set device PPPoE:ed0 set MRU 1492 set MTU 1492 set authname ** set authkey *** set log Phase Chat Connect set dial set login set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0/0 0.0.0.0/0 set timeout 0 set server +3000 *** enable tcpmssfixup disable dns set cd 5 set crtscts off enable pap disable pred1 -- -- /\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ - [EMAIL PROTECTED] http://www.FreeBSD.org The Power to Serve [EMAIL PROTECTED] http://www.TheHousleys.net - The wise man built his network upon Un*x. The foolish man built his network upon Windows. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: xargs(1) replstr patch
I'd suggest going ahead and committing it ASAP - before people start ``discussing'' it again :oI Feel free to blame me for reviewing it !!! Folks, The attached patch adds a replacement string feature to xargs(1). There's a full description in the man page update (also attached), but the following should demonstrate the new functionality: dima@spike% ./xargs -J [] echo CMD LINE [] ARGS test CMD LINE this is the contents of the test file ARGS dima@spike% ./xargs -J [] echo CMD [] LINE ARGS test CMD this is the contents of the test file LINE ARGS dima@spike% ./xargs -J [] echo [] CMD LINE ARGS test this is the contents of the test file CMD LINE ARGS This is similar to, but not identical to, the -I option described in SUSv2. The latter allows the replstr ([] above) to be attached to other arguments, and appear multiple times. Furthermore, it implies '-n 1'. Although the features are similar, they can solve different problems; even if -I is implemented later, this (-J) would still be useful. -J also doesn't have the performance implications attached with -I. There was a nice, long thread about this on current a few weeks ago (topic: Re: cp -d dir patch for review (or 'xargs'?)). It was rather inconclusive, but nobody managed to come up with a way to *properly* and *easily* imitate this functionality. Writing a script to do this *properly* (i.e., handle environment growth) isn't as easy as it sounds (although it's possible, of course). The patch is a joint effort between myself and Garance Dorsihn (gad). Comments? Suggestions? Thanks in advance, Dima Dorfman [EMAIL PROTECTED] [.] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Writing device drivers (was: help me please)
hi, Thanx Julian for pointing me to the tunnel pseudo-driver. But my major concern was regarding linking the driver to the kernel( i am trying to use static linking stuff). I am presently doing a major grep on tun 8-) It would be great if i could get some docs regding which files have to be modified so that the kernel realises my driver. So far i could figure out that the below files have to be modified( did i leave anything ) /usr/src/sys/i386/conf/* /usr/src/sys/conf/majors /usr/src/sys/conf/files That's about it. Do i really have to modify the /usr/src/sys/modules/* files??? Only if you want a module (and have a MODULE_DECLARE in your source). I would suggest that it's worthwhile spending the time making your code modular - it makes development easier and leads to better practices of ensuring that your detach cleans up all resources etc. jayesh -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Writing device drivers (was: help me please)
On Wednesday, 9 May 2001 at 10:40:50 +0530, Jayesh Krishna wrote: Hi guys... I am comfortable with Linux Device Drivers. Presently I am trying to write some pseudo-drivers in FreeBSD(4.2-Release). I tried out make_pseudo_driver.sh in the /usr/share/examples/drivers but it does not work :-( I also went through the FreeBSD Device Driver Writer's Guide by Eric L. Hernes but it seems to be outdated :-( Please someone point me out to some docs regarding writing device drivers in FreeBSD UTSL. Take a look at a similar driver and get to understand it. I'm afraid that this is an area which is woefully undocumented. You'll also get more replies if you put a useful text on the Subject: line. You should probably tell julian@ about the problems you have with make_pseudo_driver.sh. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pax(1) gzip functionality
On Thu, Apr 26, 2001 at 02:54:25AM -0700, Kris Kennaway wrote: Please review the following code from OpenBSD; it adds -z and -Z options to pax(1) to gzip(1) the archives created. Sigh. They could have generalized this just a little and supported Bzip2 at the same time. Please let me know after you commit this so I can do this. Is this necessary ? What's the problem with using a pipe ? Isn't this the same argument as the xargs one we've just gotten through ? Maybe I'm missing something... -- -- David ([EMAIL PROTECTED]) -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pax(1) gzip functionality
On Thu, Apr 26, 2001 at 04:42:44PM +0100, Brian Somers wrote: On Thu, Apr 26, 2001 at 02:54:25AM -0700, Kris Kennaway wrote: Please review the following code from OpenBSD; it adds -z and -Z options to pax(1) to gzip(1) the archives created. Sigh. They could have generalized this just a little and supported Bzip2 at the same time. Please let me know after you commit this so I can do this. Is this necessary ? What's the problem with using a pipe ? Isn't this the same argument as the xargs one we've just gotten through ? What's wrong with: tar cf - foo | gzip foo.tar.gz gzip -dc foo.tar.gz | tar xf - Someone deemed them too inconvient for the number of times they are invoked. I'm not going to enter that discussion, but _if_ gzip support is added, I feel bzip2 support should be added to be orthogonal with today's uses. Agreed. -- -- David ([EMAIL PROTECTED]) -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vm fun
Hi, If inside a syscall, what is the proper way to find the physical address of an arbitrary userland address of the current process ? Probably something like VM_PAGE_TO_PHYS - but you'll need a vm_page_t to use that. vm_page_list_find() looks promising, but I've never used it :-/ Thanks, David Rufino -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Modules with INVARIANTS
Hi, Does anyone know of a clean way to have module builds detect that INVARIANTS is defined in opt_global.h ? -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to make snp(4) devfs-friendly
I haven't actually tested the code, but looking at the patch, I think
there's a problem with it...
Specifically, on a non-devfs system - where the device nodes are
created with mknod(1), snp_clone() isn't going to be called before
snpopen().
I've (ab)used drv2 as a flag to say whether make_dev() has been
called in net/if_tun.c, but I'm not sure if this is the right answer
either :*]
Attached is a patch to make the snp(4) driver play ball with DEVFS.
For better or for worse, I used the bpf(4) driver as a guide on how to
do this.
If someone could review this, and, if nothing is wrong with it, commit
it, I'd appreciate it.
Thanks in advance,
Dima Dorfman
[EMAIL PROTECTED]
Index: tty_snoop.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v
retrieving revision 1.52
diff -u -r1.52 tty_snoop.c
--- tty_snoop.c 2001/03/26 12:41:01 1.52
+++ tty_snoop.c 2001/04/17 08:17:23
@@ -286,12 +286,9 @@
if ((error = suser(p)) != 0)
return (error);
- if (dev-si_drv1 == NULL) {
- int mynor = minor(dev);
-
+ if (dev-si_drv1 == NULL)
dev-si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO);
- make_dev(snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor);
- } else
+ else
return (EBUSY);
/*
@@ -365,6 +362,7 @@
free(snp-snp_buf, M_SNP);
snp-snp_flags = ~SNOOP_OPEN;
dev-si_drv1 = NULL;
+ destroy_dev(dev);
return (snp_detach(snp));
}
@@ -505,10 +503,25 @@
static void snp_drvinit __P((void *unused));
static void
+snp_clone(void *arg, char *name, int namelen, dev_t *dev)
+{
+ int u;
+
+ if (*dev != NODEV)
+ return;
+ if (dev_stdclone(name, NULL, "snp", u) != 1)
+ return;
+ *dev = make_dev(snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600,
+ "snp%d", u);
+ return;
+}
+
+static void
snp_drvinit(unused)
void *unused;
{
+ EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000);
cdevsw_add(snp_cdevsw);
}
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to make snp(4) devfs-friendly
This looks good. I'd say you should commit the change yourself -
feel free to say it's reviewed by me.
As an aside, when I did this to if_tun, I chose to do all the
destroy_dev()s at module unload time (I guess the snp device could do
with a MODULE_DECLARE). This allows the administrator to relax the
driver-chosen permissions on tun devices with something like
kldload if_tun
/dev/tun0
chmod blah /dev/tun0
The destroy_dev() added to snpclose() prevents this.
Having said all that, it's unlikely that anyone would want to relax
the permissions a snoop device that wasn't already opened, so the
destroy_dev() looks ok here in practice.
Brian Somers [EMAIL PROTECTED] writes:
I haven't actually tested the code, but looking at the patch, I think
there's a problem with it...
Specifically, on a non-devfs system - where the device nodes are
created with mknod(1), snp_clone() isn't going to be called before
snpopen().
I've (ab)used drv2 as a flag to say whether make_dev() has been
called in net/if_tun.c, but I'm not sure if this is the right answer
either :*]
I think the correct approach is to check for !(si_flags SI_NAMED) as
done in rev. 1.68 of sys/net/bpf.c (that rev. has a precedence bug,
which has since been fixed). That was written by phk, who I take to
be pretty authoritative on the subject; looking at the places SI_NAMED
is used also supports this conclusion.
A corrected patch is attached (although I didn't test it in the
non-devfs case).
Thanks!
Dima Dorfman
[EMAIL PROTECTED]
Index: tty_snoop.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v
retrieving revision 1.52
diff -u -r1.52 tty_snoop.c
--- tty_snoop.c 2001/03/26 12:41:01 1.52
+++ tty_snoop.c 2001/04/17 09:16:52
@@ -287,10 +287,10 @@
return (error);
if (dev-si_drv1 == NULL) {
- int mynor = minor(dev);
-
+ if (!(dev-si_flags SI_NAMED))
+ make_dev(snp_cdevsw, minor(dev), UID_ROOT, GID_WHEEL,
+ 0600, "snp%d", dev2unit(dev));
dev-si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO);
- make_dev(snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor);
} else
return (EBUSY);
@@ -365,6 +365,7 @@
free(snp-snp_buf, M_SNP);
snp-snp_flags = ~SNOOP_OPEN;
dev-si_drv1 = NULL;
+ destroy_dev(dev);
return (snp_detach(snp));
}
@@ -505,10 +506,25 @@
static void snp_drvinit __P((void *unused));
static void
+snp_clone(void *arg, char *name, int namelen, dev_t *dev)
+{
+ int u;
+
+ if (*dev != NODEV)
+ return;
+ if (dev_stdclone(name, NULL, "snp", u) != 1)
+ return;
+ *dev = make_dev(snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600,
+ "snp%d", u);
+ return;
+}
+
+static void
snp_drvinit(unused)
void *unused;
{
+ EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000);
cdevsw_add(snp_cdevsw);
}
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ffs dirpref speedup
There's a (maybe overly simple) avoidance algorithm for this. It attempts to ensure that it doesn't end up filling up cgs with directories and no files. There are also two tunables int32_t fs_avgfilesize; /* expected average file size */ int32_t fs_avgfpdir; /* expected # of files per directory */ aimed at being able to tune things such as squid caches (and I would guess the ports tree). We discussed this a while back; it has some interesting (and in some cases) undesirable side-effects. FFS tries to balance directories across CGs in order to balance the use of CGs for file allocation. The approach being advocated here will tend to use CGs one at a time, resulting in poor distribution of files and corresponding fragmentation problems. I wonder whether FreeBSD has this improvement or not. With softupdates or async mounted filesystems it seems that the speedup is very big... Thanks, -- Attila Nagye-mail: [EMAIL PROTECTED] Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 -- Forwarded message -- Date: Sat, 7 Apr 2001 02:02:21 +0400 From: Grigoriy Orlov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: CVS: cvs.openbsd.org: src On Fri, Apr 06, 2001 at 10:27:55PM +0100, Brian Somers wrote: CVSROOT:/cvs Module name:src Changes by: [EMAIL PROTECTED]2001/04/06 14:43:31 Modified files: sys/ufs/ffs: fs.h ffs_alloc.c ffs_vfsops.c sbin/fsck_ffs : setup.c sbin/tunefs: tunefs.c Log message: Replace FFS directory preference algorithm(dirpref) by new one. It allocates directory inode in the same cylinder group as a parent directory in. This speedup file/directory intensive operations on a big file systems in times. Don't forget to recompile fsck_ffs with updated fs.h or you will get "VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE" at the next boot. In any case you can ignore this error safely. Requested by deraadt@ Do you have any numbers or statistics ? Just curious as to how big/small the gain is These results is old and I improve algorithm after these tests was done. Nevertheless they show how big may be perfomance speedup. I have done two file/directory intensive tests on a two OpenBSD systems with old and new dirpref algorithm. The first test is "tar -xzf ports.tar.gz", the second is "rm -rf ports". There ports.tar.gz - port collection from OpenBSD 2.8 release, it contains 6596 dirs and 13868 files. The test systems are: 1. Celeron-450, 128Mb, two IDE drives, the system at wd0, file system for test is at wd1. Size of test file system is 8 Gb, number of cg=991, size of cg is 8m, block size = 8k, fragment size = 1k OpenBSD-current from Dec 2000 with BUFCACHEPERCENT=35 2. PIII-600, 128Mb, two IBM DTLA-307045 IDE drives at i815e, the system at wd0, file system for test is at wd1. Size of test file system is 40 Gb, number of cg=5324, size of cg is 8m, block size = 8k, fragment size = 1k OpenBSD-current from Dec 2000 with BUFCACHEPERCENT=50 Test Results tar -xzf ports.tar.gz rm -rf ports mode old dirpref new dirpref speedup old dirpref new dirpref speedup First system normal 667 472 1.41 477331 1.44 async 285 144 1.98 130 14 9.29 sync 768 616 1.25 477334 1.43 softdep413 252 1.64 241 38 6.34 Second system normal 329 81 4.06 263.5 93.5 2.81 async 302 25.711.75 112 2.26 49.56 sync 281 57.0 4.93 263 90.5 2.9 softdep341 40.6 8.4284 4.76 59.66 "old dirpref" and "new dirpref" columns give a test time in seconds. speedup - speed increasement in times, ie. old dirpref / new dirpref. - If you want a more detailed algorithm description, please sent mail to me directly. Grigoriy. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of v
Re: Vinum stripe size (was: tuning a VERY heavily (30.0) loaded server)
On Tuesday, 20 March 2001 at 11:11:44 -0600, Michael C . Wu wrote: [Lengthy email, bear with me please, it is quite interesting. This box averages 30.0 load with no problems.] snip Average file size is about 4K. /home/bbsusers* is on a vinum stripe'd volume with 3 Ultra160 9G 1RPM drives on sym0 at stripe size 256K, Greg: I know this should be a prime number, No, there's no requirement for it to be a prime number. The only problem is that with 32 MB cylinder groups and a power of two stripe size and subdisk count, you end up with all the superblocks on one subdisk, which is a performance issue. Choose the stripe size so that the superblocks are roughly evenly distributed. A performance issue ? Surely you've misspelt ``reliability'' ? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Control messages.
I can't see where in the kernel we're *not* using CMSG_DATA(). This
was fixed a while ago and tested ok on beast (for 3 descriptors
AFAIR). Are we looking at the same code (I'm looking in /sys/kern) ?
The only dodgy thing I see in there is the COMPAT_OLDSOCK stuff in
uipc_syscalls.c, and that has a very nice disclaimer:
/*
* We assume that old recvmsg calls won't receive access
* rights and other control info, esp. as control info
* is always optional and those options didn't exist in 4.3.
* If we receive rights, trim the cmsghdr; anything else
* is tossed.
*/
I was looking at our implimention of passing descriptors and
credentials over unix domain sockets (I want to add the ability to
pass more than one message at a time). According to Steven's book
you should use the CMSG_DATA macro to find the data in associated
with a struct cmsghdr. We define this macro as:
#define CMSG_DATA(cmsg) ((u_char *)(cmsg) + \
_ALIGN(sizeof(struct cmsghdr)))
However, the kernel seems to get the address of the data by looking
at (void *)(cmsg[1]). Some applications either find the data either
using the kernel's method or by using:
struct blah {
struct cmsghdr header;
sturct wibble data;
};
and taking the address of "data". Fortunately all these methods are
the same on the i386 'cos the sizeof(sizeof(struct cmsghdr)) is a
multiple of the alighment size. However on the alpha the alignment
requirement is 8 bytes and so:
CMSG_DATA(cmsg) != (cmsg[1])
If you use the struct method then offset of "data" will line up
with one or the other of these depending on the alignment requirements
of data.
I'd like to change the code to always use the CMSG_DATA method,
which will change the ABI on the alpha. This shouldn't cause too
much disruption as descriptor and credential passing is rarely
used. (I think ppp and maybe some rpc stuff use it - not much
else does).
(As far as I can tell descriptor passing for a large number of
descriptors will panic an alpha running FreeBSD too. If anyone can
give access to an alpha that it's OK for me to crash I can test
this).
David.
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Vinum stripe size (was: tuning a VERY heavily (30.0) loaded server)
On Tuesday, 27 March 2001 at 9:39:36 +0100, Brian Somers wrote: On Tuesday, 20 March 2001 at 11:11:44 -0600, Michael C . Wu wrote: [Lengthy email, bear with me please, it is quite interesting. This box averages 30.0 load with no problems.] snip Average file size is about 4K. /home/bbsusers* is on a vinum stripe'd volume with 3 Ultra160 9G 1RPM drives on sym0 at stripe size 256K, Greg: I know this should be a prime number, No, there's no requirement for it to be a prime number. The only problem is that with 32 MB cylinder groups and a power of two stripe size and subdisk count, you end up with all the superblocks on one subdisk, which is a performance issue. Choose the stripe size so that the superblocks are roughly evenly distributed. A performance issue ? Surely you've misspelt ``reliability'' ? I don't see a reliability issue here. I believe the only issue with having all your superblocks on one disk is a reliability thing - if you lose the disk you lose your superblock(s). Surely the only performance problem would be that of locality - if you use the partition a bit, that ``problem'' should go away though. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPPD!
Hi! Does anybody know about support pppunit in the ppp conf files, or may be can advice me where I can read about pppunit. Thank you very much. I'm afraid I can't really help, but I believe ppp(8) can do the same thing with the -unit command line switch. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inheriting the nodump flag
Attached below is a port of NetBSD's patch to FreeBSD's dump(8). dump's tree walker is a little weird, so the patch is a little more complicated than calling fts_set with FTS_SKIP. For the technical details of what it does, see: http://lists.openresources.com/NetBSD/tech-kern/msg00453.html. [.] Comments? Just that I noticed a typo in a comment where ``inherited'' is misspelt ``herited'' going via your URL but it's fixed in the attached patch :-) It's probably worth updating the web page. I'd certainly like to see this committed - I'm sick of backing up release directories, cvs repositories and /usr/obj :-) Thanks in advance Dima Dorfman [EMAIL PROTECTED] Cheers. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: character device driver
[.] In my mind, it is important that (in the general case) we provide a struct file state hook rather than having per-process state, to allow things like threads, process teams, aio, file descriptor passing, etc, to work properly. One advantage to tying VFS statefulness to device statefulness is you get some nice benefits like guarantees about open/close pairs on devices. I think there aren't too many VFS complications -- the only complications might be if vnodes are ever used for relevant calls (ioctl, read, write, ...) without a VOP_OPEN first -- a few used to exist but I think those have been cleaned up. IMHO phk's recent suggestion on -arch was excellent. The idea is that a driver calls make_dev() with some sort of CLONE flag. When a lookup() happens and devfs sees that the path points to such a device, it asks the driver for a udev_t. The driver may (if it wants to) call make_dev(), and then returns the udev_t. devfs creates the vnode and returns it to the caller. The VOP_OPEN then happens as usual. (I'm not sure what magic devfs needs to do with the nameidata at this point). The good thing about this is that the driver gets to declare a minor as being a CLONE device and gets to choose whether it'll return a new minor or not for the imminent open(). fork(), exec() and dup*() will make new references to the same vnode, as will open()s of the device if the driver did a make_dev(). Some sort of locking will be required so that the driver can handle udev_t requests while others are outstanding... I'd like to implement something (if I ever get the time) and post patches to -arch phk, as this seems to solve all the problems I know of :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ADSL and PPPoE question
[.] I thought something like this: [ISP] | | - Office [ADSL] | | [FreeBSD Box] | | | | | | | | [A][B][C][D] where A, B, C, D all have their own routable IPs. So according to what you said, FreeBSD would need to establish a separate PPPoE session for each of the computers A, B, C and D, provided the ISP supports multiple PPPoE sessions over the single ADSL line? The FreeBSD box should run a single PPPoE session to your provider over the ADSL link. If your provider will route more than one IP to you then you can simply run ppp(oE) without the NAT switch and it'll just work. Use the same IP on the FreeBSD box's internal network interface as you're using on the local end of the ADSL PPPoE session. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On Thu, Feb 08, 2001 at 04:58:17AM -0800, Julian Elischer wrote: =20 Looks like some way of clustering this might achieve a lot. =20 what does systat -vmstat or vmstat 1 show? Better still, I guess we could do a linux-truss and see what it's doing... I believe that it's strace under linux. If someone can provide me with a binary of this tool I'll happily run it here and see what vmware's doing. Joe The problem seems to have gone away after this (kindly pointed out to me by Maxim after my other post about xsane dropping cores): : Subject: cvs commit: src/lib/libc/stdio findfp.c : Date: Wed, 7 Feb 2001 09:34:50 -0800 (PST) : From: Maxim Sobolev [EMAIL PROTECTED] : To: [EMAIL PROTECTED], [EMAIL PROTECTED] : : sobomax 2001/02/07 09:34:49 PST : : Modified files: : lib/libc/stdio findfp.c : Log: : Fix a f^Hdamn typo, which prevented to fopen() more that 17 files at once. : : Tested by: knu, sobomax and other #bsdcode'rs : : Revision ChangesPath : 1.9 +2 -2 src/lib/libc/stdio/findfp.c -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
Bruce Evans wrote: On Tue, 6 Feb 2001, Josef Karthauser wrote: I'm wondering what's changed recently to cause vmware2 running on the linuxemu to lose a lot of performance with disk I/O. Use of cmpxchg and possibly other SMP pessimizations. A couple of weeks ago I could boot win2000 under vmware2 in a matter of minutes; on today's kernel it takes 5 or 10 minutes to boot, and disk I/O is through the roof. Could someone please hit me with a clue-bat :) Read your freebsd-emulation mail :-). You are wrong Bruce, the cmpxchg discussion was regarding why running FreeBSD as a GUEST OS was slow, because the virtual machine was very slow at emulating them. That does not explain why Windows2000 and the Boot loader both slowed down by a factor or 3-6 over teh last 2 weeks. It's even slower to start up, before it has even started any emulation.. This feels like the system is massively slowing down page activations or some other sort of exceptions that are standard for vmware. The same vmware with the same guest OS (not been updated) is now much slower. Indeed. I've been doing a ``make build'' on an OpenBSD-current vm for three days (probably about 36 hours excluding suspends) on a 366MHz laptop with a ATA33 disk. This is on a Feb 4 kernel. NetBSD next -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPPoE
I think the best way to implement this is some sort of config message to the pppoe node (before the connect/listen). The NETGRAPH version of ppp(8) is capable of doing ``chat scripts'' with netgraph nodes, so it's fairly easy to configure the node configuration conversation... Hopefully now that Christmas is over I'll be able to get back to netgraph'ifying ppp :-) Felix-Antoine Paradis wrote: To get pppoe to work, just set the options in the kernel and use a good config (ppp.conf) and use pppd. On Mon, 22 Jan 2001, Daniel C. Sobral wrote: It seems I need the following parameters to get my PPPoE to work. Could we have these options, please? -f disc:sess The -f option sets the Ethernet frame types for PPPoE discovery and session frames. The types are specified as hexadecimal numbers separated by a colon. Standard PPPoE uses frame types 8863:8864. You should not use this option unless you are abso lutely sure the peer you are dealing with uses non- standard frame types. If your ISP uses non-stan dard frame types, complain! Definitly complain! This is equivalent to calling a protocol tcp/ip but using a first byte in the packet. I will look at a configuration message for the netgraph node but Brian will hav eto work out how to send it, and where the configuration parameter should be set to do this.. The other possibility is a sysctl. -S service_name Specifies the desired service name. pppoe will only initiate sessions with access concentrators which can provide the specified service. In most cases, you should not specify this option. Use it only if you know that there are multiple access concentrators or know that you need a specific ser vice name. If you are talking about the netgraph based pppoe, then -xxx type flags are not how you configure it. I think you are talking about the (rather inefficient) userland ppp daemon. the service name requested is already an argument in the pppoe configuration. "If a PPPoE:iface[:provider] specification is given, ppp will at- tempt to create a PPP over Ethernet connection using the given iface interface by using netgraph(4). " In this case the "provider" is the service name. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ from Perth, presently in: Budapest v -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPP failures in 4.2-STABLE
Hi, The only thing that comes to mind here is that perhaps you've got something like hylafax or mgetty running against the same port and something's gone wrong with the port locking code. It *looks* like something's writing fax commands to your modem at the same time as you're trying to dial Hi all, After updating to 4.2-STABLE (previous version was 4.1.1-RELEASE) I'm having some strange problem with ppp. When I try to connect for the first time to an ISP the following occurs: ppp[177]: tun0: Chat: Send: ATDT22334455^M ppp[177]: tun0: Chat: Expect(120): CONNECT ppp[177]: tun0: Chat: Received: ATDT22334455^M^M ppp[177]: tun0: Chat: Received: +FHS:11^M ppp[177]: tun0: Chat: Received: ^M ppp[177]: tun0: Chat: Received: OK^M ppp[177]: tun0: Chat: Parent notified of failure (I press ^c here because nothing happens) Then, I try again and it works fine, but If the time between the first and the second connection is too long I receive the same error again, so I can't wait too much to do the second try. Another error that I got these days is the following (a bit like the previous one but with something more): ppp[315]: tun0: Chat: Send: ATDT22335040^M ppp[315]: tun0: Chat: Expect(120): CONNECT ppp[315]: tun0: Chat: Received: ATDT22335040^M^M ppp[315]: tun0: Chat: Received: +FCO^M ppp[315]: tun0: Chat: Received: ^M ppp[315]: tun0: Chat: Received: +FHS:11^M ppp[315]: tun0: Chat: Received: ^M ppp[315]: tun0: Chat: Received: OK^M ppp[315]: tun0: Chat: Parent notified of failure (I press ^C here because nothing happens) When dialing to this particular ISP other strange thing happens, cause even if I try for the second time (without spending too much time bet- ween the two tries) ppp aborts the operation: ppp[325]: tun0: Chat: Send: ATDT22335040^M ppp[325]: tun0: Chat: Expect(120): CONNECT ppp[325]: tun0: Chat: Received: ATDT22335040^M^M ppp[325]: tun0: Chat: Received: CONNECT 50666/ARQ/V90/LAPM/V42BIS^M ppp[325]: tun0: Chat: Parent notified of failure (I didn't press ^C this time) The relevant parts of my ppp.conf follows: # ppp.conf default: set log command chat tun connect set device /dev/cuaa1 set speed 115200 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 15 \"\" AT OK-AT-OK ATE1Q0 OK isp1: set redial 1 50 set phone 22334455 set authname isp1-user set authkey isp1-pass set timeout 80 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR isp2: set phone 22335040 set authname isp2-user set authkey isp2-pass set timeout 100 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR # EOF My modem is a internal USRobotics 56k (x2/v90) and as additional information this doesn't happen in Linux (2.2.17). If this isn't the correct mailing list forgive me please (perhaps -stable would be the one, but anyway). Thanks in advance, Giovanni P. Tirloni mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] fone: +55 44 225 6267 -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPPoE w/ nat auto fragmentation hack? (use tcpmssd port)
ppp will run programs as the user id that invoked ppp rather than using the effective user id (ie, it runs things as *you*, not *root*). Mmm-mmh. In my case, since ppp is started at boot time, the only user that ever invokes it is root, hence the tcpmssd thingy is run as root. As confirmed by the multiple "ps" I ran: euid == ruid == svguid == 0. A good ``first step'' is to run ! sh -c "/usr/local/bin/tcpmssd -p 12345 -i INTERFACE /tmp/log 21" so that you can get to see any error messages - ppp redirects I/O to Yup, tried that, here's what I get: start *** Wed Nov 15 13:30:12 PST 2000 id says: uid=0(root) gid=0(wheel) groups=0(wheel) HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin 01001 divert 1234 tcp from any to any out xmit tun0 setup The rule gets inserted, tcpmssd runs as root, and I feel like a dummy. Any other ideas? Thanks for the help Brian, I'm not sure what the problem could be - can you confirm that everything's seen if you divert everything ? --Renaud - Original Message - From: Brian Somers [EMAIL PROTECTED] To: Renaud Waldura [EMAIL PROTECTED] Cc: Brian Somers [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 15, 2000 4:32 PM Subject: Re: PPPoE w/ nat auto fragmentation hack? (use tcpmssd port) Maybe I'm just being boneheaded, but... ! sudo ipfw add 4 divert 12345 all from any to any via INTERFACE ! sudo /usr/local/bin/tcpmssd -p 12345 -i INTERFACE I was under the (tested confirmed) impression that programs executed by ppp are run under uid 0. Eg. I don't use "sudo" but the ipfw rule is added anyway, and tcpmssd is run as root. But maybe a sudo environment brings something else? That could explain a lot right there. --Renaud ppp will run programs as the user id that invoked ppp rather than using the effective user id (ie, it runs things as *you*, not *root*). AFAIK, sudo will not muck about with your environment A good ``first step'' is to run ! sh -c "/usr/local/bin/tcpmssd -p 12345 -i INTERFACE /tmp/log 21" so that you can get to see any error messages - ppp redirects I/O to /dev/null by default. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPPoE w/ nat auto fragmentation hack? (use tcpmssd port)
Maybe I'm just being boneheaded, but... ! sudo ipfw add 4 divert 12345 all from any to any via INTERFACE ! sudo /usr/local/bin/tcpmssd -p 12345 -i INTERFACE I was under the (tested confirmed) impression that programs executed by ppp are run under uid 0. Eg. I don't use "sudo" but the ipfw rule is added anyway, and tcpmssd is run as root. But maybe a sudo environment brings something else? That could explain a lot right there. --Renaud ppp will run programs as the user id that invoked ppp rather than using the effective user id (ie, it runs things as *you*, not *root*). AFAIK, sudo will not muck about with your environment A good ``first step'' is to run ! sh -c "/usr/local/bin/tcpmssd -p 12345 -i INTERFACE /tmp/log 21" so that you can get to see any error messages - ppp redirects I/O to /dev/null by default. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPPoE w/ nat auto fragmentation hack? (use tcpmssd port)
On Tue, 14 Nov 2000, Renaud Waldura wrote: -Dear hackers, - - What exactly does not work? - What does the option -l do? - -When launched automatically by ppp, tcpmssd doesn't get any of the packets -and is useless. When I start it manually from the command line, it works -fine. - -I realize this isn't much in the way of helpful debugging information, and -was hoping to further define this: I implemented that "-l" option to log all -the packets processed by tcpmssd. I'm not even sure this bug applies to -anybody else, which is why I did not seek help or publicize it until now. - -Anyway, I haven't been able to figure out what the problem is (and am -lacking time now). The best I have is this: when launched by ppp, tcpmssd -never seems to return from the main select() call. Ruslan, if you feel like -an account on the machine where I'm using this could help, just let me know -and I will gladly give you one. It does not work for me either. Start the script in rc.local rather than ppp.linkup works fine. What are you doing in ppp.linkup ? When I add this: ! sudo ipfw add 4 divert 12345 all from any to any via INTERFACE ! sudo /usr/local/bin/tcpmssd -p 12345 -i INTERFACE everything seems to work ok -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPPoE w/ nat auto fragmentation hack?
Hi, Any of you happened to hack the PPPoE support on Fbsd 4.x to automatically fragment the IP datagram if whatever device behind the NAT refuses to adjust its MTU? There's a ``tcpmssd'' port. Thanks -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPP patch (CHAP81 + MPPE)
Hi, Thanks for the patches. I've committed the changes although I'm having problems with MPPE. I suspect the problems are actually in the CCP stuff though - and I've suspected this for some time, something to do with running ppp back-to-back (and not over a tty). I'll look into this soon. Anyway, thanks again for your work. It's really appreciated. Hi! Here is a patch attached (made from current from 2813). Patch makes ppp able to respond and initiate MS-CHAP-v2 authentication and supports MPPE encryption protocol. With all these ppp can participate in MS VPN. Please look at this, and tell me what you think? Bye! [.] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Making /etc/defaults/rc.conf a configuration file.
Hi, With these patches, and the new tiny util 'sourceconf', we can make /etc/defaults/rc.conf and /etc/defaults/periodic.conf configuration files again, such that they can be parsed by things other than 'sh'. [.] Looks good to me ! -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mergemaster RFC (long)
Another thing that would be very useful is that during a merge of two files that it's possible to specify both the left hand side and the right hand side. That would fix cases like: Orig: # $FreeBSD: src/etc/shells,v 1.4 SOMEDATE$ # # List of acceptable shells for chpass(1). # Ftpd will not allow users to connect who are not using # one of these shells. /bin/sh /bin/csh /usr/local/bin/zsh The new 1.5 version has: /bin/tcsh in it. Mergemaster won't let me have both my /usr/local/bin/zsh and the /bin/tcsh. During merge I can have either but not both :( Joe You can ``e b'' (edit both) from the sdiff prompt. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mergemaster RFC (long)
Brian Somers [EMAIL PROTECTED] wrote:
First, the things I am definitely going to do. Christian "naddy"
Weisgerber has taken on the task of porting mm to openbsd.
I think it would be nice to aim to keep the two scripts exactly the
same, using `uname` when it's really necessary.
If I have interpreted the noises Theo has made correctly, he wants
mergemaster in the base tree. I don't think he'll keep a "case
`uname` ..." in there.
Of course if we didn't need it... that'd be far better :-)
Most of the diff deals with two simple differences:
- mergemaster uses "read -p prompt" throughout. That fails for
OpenBSD's /bin/sh (pdksh), where "read -p" means something entirely
different.
That's not too bad as the read -p can be changed to echo/read.
- On OpenBSD, "install" is synonymous to "install -c". FreeBSD still
has the old behavior where plain "install" deletes the source file.
Maybe the best bet here is to have ``INSTALL=install'' at the top of
the script (``INSTALL="install -c" for FreeBSD). It's a difference,
but managable.
If we can get rid of those, the actual differences become more
visible.
Oh, and changing every instance of "FreeBSD" into "${OPSYS}" or
some such would remove another few diff lines.
Aye. Looks like we're thinking along the same lines.
I'll have to talk to Wes at BSDCon about trying to get the NetBSD
guys to introduce it there too - maybe some of the NetBSD developers
will be there too.
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: mergemaster RFC (long)
[.] First, the things I am definitely going to do. Christian "naddy" Weisgerber has taken on the task of porting mm to openbsd. He has made some very reasonable requests that will make his life easier and reduce gratuitous differences between versions. Also, several people have asked for the ability to specify DESTDIR, which is an easy fix and definitely an understandable request. I think it would be nice to aim to keep the two scripts exactly the same, using `uname` when it's really necessary. IMHO this really helps when maintaining code - if there are different versions, the tendency is to update the one you use most, and ``mean to get around to'' updating the other(s) later. Of course the ``later'' tends to stop happening after a while... [.] script. I'm going to add variables to the .mergemasterrc file for mergemaster-start and mergemaster-end scripts (names may change). These scripts will run after the temproot environment is built, and after mm is done with it's run. These scripts would be source'd from within mm so all the variables will be available to them. This should allow people to add in their own "options" that I don't want to add to the program. I like this idea. Perhaps the man page should have a HOWTO section that describes how to ``not compare files'' by deleting them in the start script etc. This is cobbled together from various people's suggestions. We need a list of files somewhere (probably in .mergemasterrc) that people don't ever want to have to deal with via the "normal" mm process. If a file on that list has been updated (according to the cvs tag) then instead of presenting that file to the user, it will be ignored the first time through. Then, at the end of the script there will be a printout similar to what happens when the user leaves a file to do by hand later. Something like: I think having IGNOREFILES="a b c" isn't necessary when it's as easy to have rm a b c in your start script. It seems like overkill to handle ignored files specifically. Next on the list of things I'm open to suggestions on is a small script I wrote that compares the variables in /etc/rc.conf[.local] to the ones in /etc/defaults/rc.conf, and does the same for make.conf. [.] I don't really think it matters where this happens in mergemaster, but it would be nice to include periodic.conf too. Of course you can't generically include everything in defaults/ as pccard.conf is probably something to avoid. This also brings up the question of which files in /etc are good to examine before a world build. [.] Yes, too much handholding I think. There was a PR filed in regards to the current situation with the new sendmail moving the aliases file to /etc/mail, and mergemaster's [.] Yep, this is definitely an SEP ! I have an idea related to getting users to actually READ the man page [.] Yeuch ! :-) And the last of the ideas I want feedback on is related to the problem of determining permissions on the files to be installed. To my knowledge [.] Perhaps the best thing here is to make mtree capable of understanding rwxrwxrwx type modes, and then generate an mtree spec file based on the stuff in temproot and apply it to destdir ? Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
The majority of these programs could be handled by adding knowledge of "-" as a magic filename to fopen(3). [.] I would argue that the programs and the scripts that call them are already broken, but hey... So (just to add fuel to the mass opposition), do this without temporary files: count=$(program | tee /dev/stderr | wc -l) exit $count But then, you also said: At the same time I would really love if we implemented "|.*" to mean "do an popen(3)" instead. so I guess this could result in count=$(program |. cat | wc -l) exit $count (substitute correct "|.*" syntax - whatever that is). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Redirect stdout/stderr to syslog [OFF-TOPIC]
Hi, I wonder if it is possible to redirect stdout/stderr to syslog. Background: I'm writing a program which starts (fork=execvp) and observes another program. I would like to redirect all output of the "execvped" program to syslog. I know this is not really FBSD related but I hope you can help me anyway. Please don't tell me that I should redirect the output to a file and not to syslog. I know how to redirect the output to a file (that's my prog doing at present state). I guess you could do something like: int fd; fd = open(_PATH_DEVNULL, O_RDONLY); dup2(fd, STDIN_FILENO); close(STDOUT_FILENO); openlog(); dup2(STDOUT_FILENO, STDERR_FILENO); Bye, Alex -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Critical (or equivalent) section in Userland?
In message [EMAIL PROTECTED] Karl Pielorz writes: : I'm writing a program under FreeBSD 3.X that has been forced into having to : make a number of rename() calls that must be completed atomically (i.e. all : together) without the process being interrupted, or any other process being : allowed to run... If advisory locks won't work (and they almost always will for things like this), then you could walk the process tree. For all processes that aren't suspended or yourself, send a SIGSTOP, keep a list. Keep going through the tree while you keep finding processes. SIGSTOP can't be caught or blocked, so you know you've stopped them). Do your operation, then send SIGCONT to all the processes that you sent a SIGSTOP to. Of course, this will likely be much harder than doing advisory locking, but might be a way that you might be able to exactly what you want. Wow, forgive me for saying this, but it must take a warped mind to think of that !!! :-) Now if the original poster could arrange that all the files are either in the same directory or symlinked to the same directory, a quick directory rename (or symlink move) may do the job. If that's not atomic enough, you could always replace that chunk of filesystem with a mount(). Warner P.S. Can you tell I'm partial to advisory locks? -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does sio have a maintainer?
Hi folks, Does the sio driver have a maintainer? There are two PR's open that contain patches to provide support for new devices, but I can't find anyone to pin them on. :-) I thought bde looked after sio.c... Dunno if he reads this list. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing device drivers (ioctl issue)
I ran into this same problem when modifying the vmmon VMWare driver for FreeBSD to support mulitple emulator instances. FreeBSD's VFS does not have a concept of stateful file access: there are open's and close's, but the VOP_READ/WRITE operations are not associated with sessions. This [.] There are a number of possible solutions to this problem, including the [.] My preferred solution, and I actually hacked around with a kernel a bit to do this, is to make the VFS provide (optional) stateful vnode sessions. vop_open() would gain an additional call-by-reference argument, probably a void**. When NULL, the caller would be requesting a stateless vnode open, [.] My changes are incomplete as I was working on it on the plane, and comments on the idea would be welcome. One thing this would allow is for [.] I think this is something that BSD lacks big-time. It simplifies the way userland opens devices and should be fairly easy to implement. If you haven't got time, I'd be willing to pick this up. Do you have anything worth sending me (patches) ? Cheers. 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 -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc/security - /etc/periodic/security ?
Brian Somers wrote: Well, "periodic security" will work as long as /etc/periodic/security exists, so I guess you just mean the docs need updating? I'll get to that if someone is actually planning on committing this stuff. =20 Perhaps the best option is to do with the inline security option and=20 just run ``periodic security'' from cron ? I can commit the changes. I don't think there's really a problem with just running security from daily. I can add a note that this is normal practice in the manpage, and that security shouldn't be run separately unless you set daily_security_enable=3DNO or whatever the option is. Oops, sorry for the reply latency I don't think it's appropriate to separate the security script into multiple scripts unless the intention is to run ``periodic security''. This is just my personal view though. If you feel strongly about it, you should bring it up on freebsd-arch. I'll certainly back down if the concensus says it should be split. --=20 Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D BTW, congrats on your commit bit ! -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc/security - /etc/periodic/security ?
Brian Somers wrote: Well, "periodic security" will work as long as /etc/periodic/security exists, so I guess you just mean the docs need updating? I'll get to that if someone is actually planning on committing this stuff. =20 Perhaps the best option is to do with the inline security option and=20 just run ``periodic security'' from cron ? I can commit the changes. I don't think there's really a problem with just running security from daily. I can add a note that this is normal practice in the manpage, and that security shouldn't be run separately unless you set daily_security_enable=3DNO or whatever the option is. Oops, sorry for the reply latency I don't think it's appropriate to separate the security script into multiple scripts unless the intention is to run ``periodic security''. This is just my personal view though. If you feel strongly about it, you should bring it up on freebsd-arch. I'll certainly back down if the concensus says it should be split. Duh! I didn't realise -arch was already on the cc list :-/ --=20 Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D BTW, congrats on your commit bit ! -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc/security - /etc/periodic/security ?
[ x-posted to -arch to fish for complaints ]
James Howard wrote:
On Thu, 29 Jun 2000, Ben Smithurst wrote:
=20
Try the attached. They haven't been thoroughly tested, but that's what
-CURRENT is for, right? :-) I even remembered to update the manual page
this time...
=20
This needs to have knobs and stuff located in /etc/defaults/periodic.conf
Umm, which knobs? I added the only two options the security stuff currently
uses, what else does it need?
Also, it would be cool if a security option were made to periodic(8).
Well, "periodic security" will work as long as /etc/periodic/security
exists, so I guess you just mean the docs need updating? I'll get to
that if someone is actually planning on committing this stuff.
Perhaps the best option is to do with the inline security option and
just run ``periodic security'' from cron ? I can commit the changes.
If you send me some diffs, I'll commit them and then look at
introducing {daily,weekly,monthly,security}_silence flags that will
silence mails that have nothing to say.
Assuming there are no objections that is
--=20
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc/security - /etc/periodic/security ?
Will we be seeing a move in this direction towards a more configurable security script? Is anyone planning it? I am porting the scripts to Linux and will hold off on security if nothing is being planned or make the changes myself. I just do not want to duplicate efforts. Also, I found a bug with a patch in conf/19567. Please apply :) I've changed /etc/security in -current by adding switches to the scripts command line and making those switches configurable in /etc/periodic.conf. If you want to take this further, I would think it best to keep it controllable from periodic.conf - but feel free to argue about specifics :-) I wouldn't mind if you wanted to pass any patches by me. Jamie Cheers. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPPoE help me please!!
I can run tcpdump on my ethernet device ed1 and it is sending out a PADI packet but it is not getting anything back. This is either because you have an incorrect :provider setting in your ``set device'' line, or because you were using a different NIC with your provider at one point, and they've cached its MAC address. I would think it's just the wrong provider. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: buildworld summary
A few months ago someone posted a script that summarizes make buildworld as it progresses. I've searched the ports and the mailing lists but I can't find it any more :-( so I'd be grateful if someone would tell me. Thanks. It was phk (cc'd), and yes, it seems to have evaporated. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] 356 pungent unguent for stump-itch -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: buildworld summary
Brian Somers wrote: A few months ago someone posted a script that summarizes make buildworld as it progresses. I've searched the ports and the mailing lists but I can't find it any more :-( so I'd be grateful if someone would tell me. Thanks. =20 It was phk (cc'd), and yes, it seems to have evaporated. Hmm, are you sure you're not thinking of 'whereintheworld' by fenner, or isn't that what you were thinking of? Take a look at http://people.freebsd.org/~fenner/whereintheworld and see if it's what you're after. And Brian, are you sure you're not mixing it up with phk's proposals to post a list of world breakage to -current or something? Or am I just getting terribly confused? (I'll shut up now.) I'm fairly sure phk posted about 3 of these reports. I whinged about the first one because it mentioned that something didn't build and then went on to report 0 errors... --=20 Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: .core file reporting in daily report
I was trying to figureout how the periodic scripts were run when I noticed that cron had coredumped back in October and left a core file in /var/run/cron. I got to thinking, it would be nice if the daily scripts would report when core files are found so they can be cleaned up. I'm about to commit a change to the way the periodic scripts are run. You'll be able to tune this in /etc/periodic.conf shortly. Jamie -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RealSystem module for libalias
Hi, I haven't done anything with this yet, but I plan to take a look soon. This is just a note to let you know that your post hasn't gone unnoticed. The libalias allows to transport only TCP stream on the RealSystem (RealAudio and RealVideo). It can not transport UDP stream, rtsp and pna, from the real server to the client. So, I wrote the new module for the libalias to support the UDP stream on the RealSystem. The patch againt to the libalias source tree of the FreeBSD 4.0-RELEASE is available at: http://configure.sh/FreeBSD Any comments are welcome. --- Junichi Satoh [EMAIL PROTECTED] / [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RealSystem module for libalias
Brian, this is just to let you know that: 1) I am currently in process of applying *big* PPTP patch to libalias so I would really appreciate it if you do not touch libalias before I finish with PPTP part. Ok, no problem - I'm pretty busy at the moment anyway. 2) Erik Salander [EMAIL PROTECTED] is working together with Mr. Junichi on $Subject issue (see attached), so you will probably want to contact them directly, since I am not particularly interested in these changes. But I would appreciate if you send me the patch for review before you commit it. Absolutely - I planned to anyway. Cheers. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux and FreeBSD dual universe
In message [EMAIL PROTECTED], Bill Pechter write s: Date: Thu, 25 May 2000 09:42:51 -0700 (PDT) From: "Duane H. Hesser" [EMAIL PROTECTED] Subject: Re: FreeBSD kernel as a replacement for Linux kernel Anyone remember the old Pyramid OSX 'universe' command? command like "att ls", or even "att cc ". The universe was marked by a flag which affected the interpretation of "conditional symbolic links". A separate syscall was available to create It did nøt use variant symbolic links, it used a namei hack. If you had a directory containing: . .. .ucbfoo .attfoo bar and you were in universe "ucb" you would see: . foo bar where "foo" would take you to ".ucbfoo" it was that simple. I believe it was Sequent's ``Dynix'' that had the flag-dependent symbolic links. Sysv in those days didn't do symlinks at all ! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file creation times ?
Such editors are broken. What if the file is a symlink ? IMHO open() write() write() write() ftruncate() close() is the only way. If that is the only way, then emacs is of course broken. (And I disagree - I use emacs every day...) Now there's an argument waiting to happen :-) So if you create a file and make it writable by me and I edit it, it becomes mine ? Good ol' emacs ! I would guess that in real life it *must* be smart enough not to do this (I don't have access to emacs from here right now). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file creation times ?
[.] I check it in FreeBSD 4.0-R open do not change atime. Indeed, but it sets a bunch of flags that can be referred to later by the driver. This would be a good flag - perhaps limited in the same way that touching the file is (owner only). [.] -- @BABOLO http://links.ru/ -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux emu question
I noticed some people talking about the linux emulation and how good/bad it can be and I just wondered, does anybody here have any experiences with the vmware for linux software? I have been thinking of buying this, for those one or two windows programs that I need to use now and then. To add to the other responses I run OpenBSD-current under VMware2 (on my FreeBSD-current laptop) and also run NT4 when I need to read lotus scrotes mail at work. It's very stable (bar the recent module changes which are probably now fixed with the latest vmware2/Makefile update). Mark Knight (cc'd) runs FreeBSD-current in a vmware2 box under NT very successfully up until about a week ago (he's having some nasty panics with currents built within the last week). Julian Elischer runs FreeBSD-current under vmware? on a FreeBSD-current box with no complaints afaik. Just wondering, It's worth the $99 in my book ! James. --- ICQ #19675056 Public key available at: http://www.dreamscape.com/halstead/jh.asc --- -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
