NEW IPFW FEATURE [PATCHES]: Dynamic rule expiration lifetime fine-grained control
Please read the bulk of my message in the Description: section below...
Submitter-Id: current-users
Originator:Aaron Gifford
Organization: N/A
Confidential: no
Synopsis: NEW IPFW FEATURE [PATCHES]: Dynamic rule expiration lifetime
fine-grained control
Severity: non-criticial
Priority: medium
Category: kern
Class: change-request
Release: FreeBSD 4.3-STABLE i386
Environment:
System: FreeBSD my.host.name 4.3-STABLE FreeBSD 4.3-STABLE #0: Thu Jun 21 20:14:40 MDT
2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CUSTOM i386
Description:
NEW FEATURE: Fine-grained control over dynamic rule expiration using
an optional per-rule expiration lifetime
When using stateful ipfw rules, the dynamic rule expiration times
are governed by the values of the net.inet.ip.fw.dyn_*_lifetime
variables. This is an excellent attribute of the ipfw stateful
rule system. System administrators can tune overall system
rule expiration times to tailor ipfw to best suit their needs.
Unfortunately, this global tuning of rule expiration times just does
not give the ipfw power user the fine-grained control he or she needs
or wants. For example, the default 300-second (5-minute) expiration
for TCP sessions (governed by the net.inet.ip.fw.dyn_ack_lifetime
sysctl variable) in the connected state works well for TCP protocols
like HTTP where the TCP session will very likely not idle beyond
that default expiration time. But for TCP sessions like telnet or
ssh where a user may let his or her connection idle longer than
that, it is extremely annoying to discover the session frozen
because the firewall expired the dynamic rule for the session.
The system administrator could just increase the rule expiration
time, but that breaks the elegance of the default (or admin.-tuned)
global expiration setting that works well and is desireable for
most connections.
The solution is quite simple: add an option to override the default
sysctl variable settings for TCP sessions in the connected state,
and also for UDP sessions. With such an option, ipfw rules that
do not use the option behave as they do now. Rules that use the
option can override the default sysctl settings on a per-rule basis.
Here's an example:
OLD IPFW RULES:
ipfw add check-state
ipfw add deny tcp from any to any established
ipfw add allow tcp from me to any keep-state out setup
...
ipfw add allow udp from me to any 53 keep-state out
ipfw add allow udp from me to ${icq} 4000 keep-state out
...
With the above rules, the host can create new outbound TCP sessions
using the default expiration times. However, users on the host who
make outbound telnet/ssh sessions (or other long-idleing sessions)
will be frusterated unless the admin. increases the global default
expiration lifetime. And if the admin. does this, he/she increases
consumption of system resources in cases of outbound TCP sessions
where the remote side of the connection dies during the connected
state without any indication or response, leaving the state as
connected, the dynamic rule persisting longer than would otherwise
be needed.
NEW IPFW RULES:
ipfw add check-state
ipfw add deny tcp from any to any established
ipfw add allow tcp from me to any 22,23 keep-state lifetime 3600 out setup
ipfw add allow tcp from me to any keep-state out setup
...
ipfw add allow udp from me to any 53 keep-state out
ipfw add allow udp from me to ${icq} 4000 keep-state lifetime 600 out
...
Now the administrator can use the default settings for most TCP and
UDP sessions, but override the settings for specific uses. This
flexibility is very desirable.
This feature is currently in use on several FreeBSD-STABLE machines
where I work, as well as on my home machine. I know that several
other FreeBSD users have at least downloaded and looked at the patches
that add this feature. I do not know if anyone else is using it
currently.
The patches below implement this feature. The patches included here
are against the latest CVS versions of the various files as of Wed.
4 July 2001 8:00 PM MST (-0600). I also have patches against -STABLE
if anyone wants them. I have been running this patch (the only changes
over time were very minimal, line offsets, etc. to keep the patch
working against -STABLE source changes over time) for well over a
year now and it has been rock solid on Internet web server hosts as
well as on various border firewall machines.
IPFW MAINTAINERS: PLEASE, please examine the patches. If there are
no glaring errors or omissions, please consider committing them.
* The patches update the 'ipfw' man page to document the new
feature.
* Compatibility: using an unpatched ipfw with a patched kernel
or using a patched ipfw with an
Re: DEVFS behaviour
On Thu, Jul 05, 2001 at 07:57:41AM +0200, Riccardo Torrini wrote: Maybe this is a stupid(?) question, but how DEVFS is supposed to work with softlink? How can I make them reboot-resistant? See /etc/rc.devfs (which should probably be referenced in devfs(5)). -- Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org PGP signature
more make world problems on alpha.
rarpd fails to compile (again the WARNS?=2 problem. - JimP beta2 6# make cc -O -pipe -mcpu=ev4 -DTFTP_DIR=\/tftpboot\ -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -c /usr/src/usr.sbin/rarpd/rarpd.c cc1: warnings being treated as errors /usr/src/usr.sbin/rarpd/rarpd.c: In function `expand_syslog_m': /usr/src/usr.sbin/rarpd/rarpd.c:1027: warning: field width is not type int (arg 4) *** Error code 1 -- --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o [EMAIL PROTECTED] - [EMAIL PROTECTED] _'\,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more make world problems on alpha.
Yes, I found fixed that, but I haven't checked it in yet. On Thu, 5 Jul 2001, Jim Pirzyk wrote: rarpd fails to compile (again the WARNS?=2 problem. - JimP beta2 6# make cc -O -pipe -mcpu=ev4 -DTFTP_DIR=\/tftpboot\ -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -c /usr/src/usr.sbin/rarpd/rarpd.c cc1: warnings being treated as errors /usr/src/usr.sbin/rarpd/rarpd.c: In function `expand_syslog_m': /usr/src/usr.sbin/rarpd/rarpd.c:1027: warning: field width is not type int (arg 4) *** Error code 1 -- --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o [EMAIL PROTECTED] - [EMAIL PROTECTED] _'\,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On Wed, Jul 04, 2001 at 12:12:22AM -0700, Kris Kennaway wrote: This kind of language isn't called for. People make mistakes, and insulting them for it serves no useful purpose. People are making more and more mistakes that break the Alpha build. We will soon have two more arches. We need to get better in our practices -- so what do you suggest if you don't like our form of peer pressure? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On Thu, Jul 05, 2001 at 05:49:56PM -0700, David O'Brien wrote: On Wed, Jul 04, 2001 at 12:12:22AM -0700, Kris Kennaway wrote: This kind of language isn't called for. People make mistakes, and insulting them for it serves no useful purpose. People are making more and more mistakes that break the Alpha build. We will soon have two more arches. We need to get better in our practices I addressed this part in another message. -- so what do you suggest if you don't like our form of peer pressure? The issue you quoted me on above has already been resolved, but I'll still point out that peer pressure is not the same as trading of vicious insults. Kris PGP signature
Re: chgrp broken on alpha systems
On Thu, Jul 05, 2001 at 09:41:21PM -0700, Matthew Jacob wrote: Did you read my other mails? I doesn't appear that you have. Or you didn't understand them. I was laughing because, yes, WARNS was turned on prematurely which killed things. Well, your email didn't translate well, because it came across to me as if you were scoffing at the suggestion but without explaining your actual reasons for laughing. If that wasn't your intention, then okay. I have to laugh. Sorry if you don't that helps. S'long then. I've no more time for the likes of you. *rolls eyes* Man, some people are hard to work in a team with. Kris PGP signature
Re: chgrp broken on alpha systems
On Thu, 5 Jul 2001, Kris Kennaway wrote: On Thu, Jul 05, 2001 at 09:41:21PM -0700, Matthew Jacob wrote: Did you read my other mails? I doesn't appear that you have. Or you didn't understand them. I was laughing because, yes, WARNS was turned on prematurely which killed things. Well, your email didn't translate well, because it came across to me as if you were scoffing at the suggestion but without explaining your actual reasons for laughing. If that wasn't your intention, then okay. Nope, not in the slightest. I have to laugh. Sorry if you don't that helps. S'long then. I've no more time for the likes of you. *rolls eyes* Man, some people are hard to work in a team with. I work fine in teams of peers. Whups! Just pulling your leg. Can't take a joke, can you? Oh, well, such is life. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On 2001-Jul-05 20:31:43 -0700, Matthew Jacob [EMAIL PROTECTED] wrote:
Perhaps what we really need- and this is really a toolchain issues- is a
compiler that is just as stringent on i386 as on alpha?
IMHO, the compiler _is_ just as stringent on i386 as Alpha (it's the
same compiler). IMHO, the problem splits into two categories:
Firstly, sizeof(long) (and sizeof(void *)) differ between the Alpha
and the i386. Secondly, there are cases where different architectures
map foo_t onto different primitive types. Both these problems are
very difficult to solve using a lint-like tool running on only one
architecture.
As examples of the latter, a quick diff of
/sys/{i386,alpha}/include/{ansi,types}.h reveals the following:
i386 type Alpha type
clock_t unsigned long int
ptrdiff_t int long
size_t unsigned intunsigned long
ssize_t int long
off_t __int64_t long
*physaddr { int r[1]; } { long r[1]; }
label_t { int [6]; }{ long [10]; }
vm_offset_t unsigned intunsigned long
vm_ooffset_t__int64_t long
vm_pindex_t unsigned intunsigned long
vm_size_t unsigned intunsigned long
register_t __int32_t __int64_t
u_register_t__uint32_t __uint64_t
intfptr_t int long
uintfptr_t unsigned intunsigned long
Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On Fri, 6 Jul 2001, Peter Jeremy wrote:
On 2001-Jul-05 20:31:43 -0700, Matthew Jacob [EMAIL PROTECTED] wrote:
Perhaps what we really need- and this is really a toolchain issues- is a
compiler that is just as stringent on i386 as on alpha?
IMHO, the compiler _is_ just as stringent on i386 as Alpha (it's the
same compiler).
True. I didn't quite put it correctly. It's true that the compilers are
the same- but they do have different code generators, and they really do
have different levels of acceptance for errors that don't seem to be
type related.
IMHO, the problem splits into two categories:
Firstly, sizeof(long) (and sizeof(void *)) differ between the Alpha
and the i386.
Yes. This tends to be caught by the alpha compiler but the i386.
It'd be nice if there were a -Wpun. For example:
x.c:
int
func(char *p)
{
int j = (int) p;
return j + 1;
}
On i386, 'gcc -fsyntax-only -Wall x.c' produces no error. On
NetBSD/alpha (same compiler, really), this produces:
x.c: In function `func':
x.c:4: warning: cast from pointer to integer of different size
It'd be *really* nice if we could add a flag where such errors could be
checked for and emitted for an i386 build.
Secondly, there are cases where different architectures
map foo_t onto different primitive types. Both these problems are
very difficult to solve using a lint-like tool running on only one
architecture.
As examples of the latter, a quick diff of
/sys/{i386,alpha}/include/{ansi,types}.h reveals the following:
i386 type Alpha type
clock_t unsigned long int
Both should be u_int32_t until we decide Unix will last past 2038(?) in
which case they'll both be uint64...
ptrdiff_t int long
size_tunsigned intunsigned long
ssize_t int long
off_t __int64_t long
*physaddr { int r[1]; } { long r[1]; }
label_t { int [6]; }{ long [10]; }
vm_offset_t unsigned intunsigned long
vm_ooffset_t __int64_t long
vm_pindex_t unsigned intunsigned long
vm_size_t unsigned intunsigned long
register_t__int32_t __int64_t
u_register_t __uint32_t __uint64_t
intfptr_t int long
uintfptr_tunsigned intunsigned long
I'm a little out of my depth about the right thing here- my
heavy toolchain experience is = 10 years ago. I wish Bruce and/or David
could help sort this out.
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Interruptable hang starting init in today's -CURRENT
Date: Thu, 5 Jul 2001 10:44:39 -0700 (PDT) From: David Wolfskill [EMAIL PROTECTED] OK; I got today's -CURRENT built and running: FreeBSD m147.whistle.com 5.0-CURRENT FreeBSD 5.0-CURRENT #60: Thu Jul 5 09:27:49 PDT 2001 [EMAIL PROTECTED]:/common/C/obj/usr/src/sys/LAPTOP_30W i386 but it exhibits the same hanging. And sure enough, sysctl -a hangs; here's that last part of its output before it does: net.inet.tcp.local_slowstart_flightsize: 65535 net.inet.tcp.newreno: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.pcbcount: 27 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.msl: 3 net.inet.tcp.always_keepalive: 1 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.log_in_vain: 0 net.inet.udp.blackhole: 0 net.inet.accf.unloadable: 0 ^C Interestingly, sysctl -a -N spits out names, but then seems to fall into a rut: net.inet.udp.stats net.inet.udp.maxdgram net.inet.udp.recvspace net.inet.udp.pcblist net.inet.udp.log_in_vain net.inet.udp.blackhole net.inet.udp.getcred net.inet.accf.unloadable net.inet.accf.373 net.inet.accf.373 net.inet.accf.373 net.inet.accf.373 net.inet.accf.373 net.inet.accf.373 net.inet.accf.373 ... [20k more lines in a few seconds...] Looks as if it's looping with no termination conditions being matched. cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
background fsck panics?
hi, after some weeks without softupdates, i recently reenabled them on my notebook. it seems, that my problems still exist. background checking one of my partitions leads to a panic() complaining about some block too large error. sorry, i didn't capture the message, and for obvious reasons i don't like reproducing that condition. it might be useful to know, that fsck checks all other partitions without problems. moreover, that one partition that causes the problem, contains a .fsck_snapshot entry: slot 5 ino 0 reclen 444: regular, `.fsck_snapshot' any ideas? best, christian -- Sorry, no defects found. Please try a different search [http://www.cisco.com/support/bugtools/bugtool.shtml] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: I take it alpha is broken now, yes?
On 05-Jul-01 Matthew Jacob wrote: ha/alpha/genassym.c ../../../vm/vm_zeroidle.c:13: opt_npx.h: No such file or directory ../../../vm/vm_zeroidle.c:17: opt_reset.h: No such file or directory ../../../vm/vm_zeroidle.c:38: machine/pcb_ext.h: No such file or directory ../../../vm/vm_zeroidle.c:39: machine/vm86.h: No such file or directory mkdep: compile failed *** Error code 1 These are all x86 specific includes and can probably go away. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On Thu, Jul 05, 2001 at 11:00:09AM +0200, Dag-Erling Smorgrav wrote: Matthew Jacob [EMAIL PROTECTED] writes: it's just the same old same old refrain of beast is broken or oh well, etc. etc. etc but yer right, insulting does no good. I beg too much hard cider at dinner. It makes the veins in the forehead swell and makes one impatient. I have no problem with that :) And beast isn't broken, it's just that its bsd.*.mk files are too old to test WARNS patches. Actually, you can work around this if you set enough environment variables, but it certainly is annoying to do. Kris PGP signature
Re: chgrp broken on alpha systems
David claimed he would upgrade beast at some point- but he's pretty busy. 1. If I had the authority to do so, I'd drive over to Concord and do it. I can do that next week some time. 2. If I had 144KBit DSL, I'd pay the extra power bills and leave up a PC164 at Feral all the time for people to do this. 3. If I had the ability to sweet talk the NASA/Ames folks, I'd leave a machine there up all the time. If beast can't be upgraded soon, and #1 can't happen, I will make #2 happen. I have two PC164s- and one could just be left up all the time. On Thu, 5 Jul 2001, Kris Kennaway wrote: On Thu, Jul 05, 2001 at 11:00:09AM +0200, Dag-Erling Smorgrav wrote: Matthew Jacob [EMAIL PROTECTED] writes: it's just the same old same old refrain of beast is broken or oh well, etc. etc. etc but yer right, insulting does no good. I beg too much hard cider at dinner. It makes the veins in the forehead swell and makes one impatient. I have no problem with that :) And beast isn't broken, it's just that its bsd.*.mk files are too old to test WARNS patches. Actually, you can work around this if you set enough environment variables, but it certainly is annoying to do. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KLD-module(dir) naming conventions
On Fri, 6 Jul 2001, Bruce Evans wrote: ... if_foo.c - /sys/modules/foo - foo.ko. There is no driver named if_foo. that seems to be right. No man if_ed(4) yust ed(4)... Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KLD-module(dir) naming conventions
On Fri, 6 Jul 2001, Bruce Evans wrote: ... if_foo.c - /sys/modules/foo - foo.ko. There is no driver named if_foo. that seems to be right. No man if_ed(4) yust ed(4)... No. if_foo.c in /sys/modules/foo builds if_foo.ko. This was discussed a year or so back; it's a compromise design. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
Since David's busy, I'm working on it now. Just some build issues to be worked out since warnings were made fatal recently. - Jordan From: Matthew Jacob [EMAIL PROTECTED] Subject: Re: chgrp broken on alpha systems Date: Thu, 5 Jul 2001 14:17:51 -0700 (PDT) David claimed he would upgrade beast at some point- but he's pretty busy. 1. If I had the authority to do so, I'd drive over to Concord and do it. I can do that next week some time. 2. If I had 144KBit DSL, I'd pay the extra power bills and leave up a PC164 at Feral all the time for people to do this. 3. If I had the ability to sweet talk the NASA/Ames folks, I'd leave a machine there up all the time. If beast can't be upgraded soon, and #1 can't happen, I will make #2 happen. I have two PC164s- and one could just be left up all the time. On Thu, 5 Jul 2001, Kris Kennaway wrote: On Thu, Jul 05, 2001 at 11:00:09AM +0200, Dag-Erling Smorgrav wrote: Matthew Jacob [EMAIL PROTECTED] writes: it's just the same old same old refrain of beast is broken or oh well, etc. etc. etc but yer right, insulting does no good. I beg too much hard cider at dinner. It makes the veins in the forehead swell and makes one impatient. I have no problem with that :) And beast isn't broken, it's just that its bsd.*.mk files are too old to test WARNS patches. Actually, you can work around this if you set enough environment variables, but it certainly is annoying to do. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote: Since David's busy, I'm working on it now. Just some build issues to be worked out since warnings were made fatal recently. What problems? There shouldn't be any fatalities from warnings unless people have marked something with WARNS prematurely. Kris PGP signature
softupdates on /
As of a month ago or so, there was some discussion that concluded it was unsafe to enable softupdates on a root partition. Is it safe to go back in the water there, now? Cheers, Ben Benjamin P. Grubin [EMAIL PROTECTED] PGP Fingerprint: EDE9 A88F 3BCC 514A F310 FEFB 7109 2380 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: softupdates on /
In the last episode (Jul 05), Benjamin P. Grubin said: As of a month ago or so, there was some discussion that concluded it was unsafe to enable softupdates on a root partition. Is it safe to go back in the water there, now? The 2 drawbacks with SU are 1 - You can't immediately reuse the space occupied by a file you just deleted; this may bite you if you do an installworld and don't have 20MB free on /. when it comes to installing /sbin, you need 18MB for the new binaries, but you can't reuse the 18MB for the just-deleted binaries. 2 - If you create a file, SU doesn't commit it immediately; it waits a bit. If you edit rc.conf and crash (or reboot by power-cycling), you may find you don't have an rc.conf. Both have happened to me enough times that I don't enable SU on / anymore :) -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: softupdates on /
From: Benjamin P. Grubin [EMAIL PROTECTED] Date: Thu, 5 Jul 2001 19:46:54 -0400 As of a month ago or so, there was some discussion that concluded it was unsafe to enable softupdates on a root partition. Is it safe to go back in the water there, now? Well, despite the warnings, I've been running with soft updates turned on for each UFS on my laptop; although there were some cases (around 5 or 6 weeks ago, if my time sense isn't totally screwed up) where -CURRENT wouldn't stay up, and fsck was doing some Very Unpleasant Things, I was able to cope OK. However, I've configured the laptop in what is arguably a rather peculiar way: I can boot from any of 3 slices, each of which has its own / and /usr. (/var is common to all, and /usr/local, as well as /home and /cvs are all symlinks in each to a common file system.) Regardless of which slice is booted, each slice's file systems are mounted and visible. There's more detail about that stuff at http://www.catwhisker.org/~david/FreeBSD/laptop.html. I've been running the box this way since early March, and have -STABLE (from different days, or with other differences, such as experimental code) on the 1st 2 slices, and -CURRENT on the 3rd. I've been tracking each of -STABLE and -CURRENT daily (modulo a few cases where I couldn't build -CURRENT a while back). Thus, I have some levels of fallback that a more conventional layout might not have. (I also have some additional exposure, since a suitably-corrupted fsck could trash everything.) But one of my purposes here is to try things out try to help identify ( fix) any problems I see :-} Anyhow: m147[1] uname -a FreeBSD m147.whistle.com 5.0-CURRENT FreeBSD 5.0-CURRENT #60: Thu Jul 5 09:27:4 9 PDT 2001 [EMAIL PROTECTED]:/common/C/obj/usr/src/sys/LAPTOP_30W i386 m147[2] df -k Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s3a158783798076627455%/ devfs 110 100%/dev /dev/ad0s1a15878341766 10431529%/S1 /dev/ad0s1e 1870791 791927 92920146%/S1/usr /dev/ad0s2a15878341839 10424229%/S2 /dev/ad0s2e 1870791 813249 90787947%/S2/usr /dev/ad0s3e 1870751 767973 95311845%/usr /dev/ad0s3g 101630332365 902634 3%/var /dev/ad0s3h 10277074 5458487 399642258%/common procfs 440 100%/proc /dev/md10c 520140 444 478088 0%/tmp m147[3] swapinfo Device 1K-blocks UsedAvail Capacity Type /dev/ad0s3b 1048448 4688 1043760 0%Interleaved m147[4] mount /dev/ad0s3a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad0s1a on /S1 (ufs, local, soft-updates) /dev/ad0s1e on /S1/usr (ufs, NFS exported, local, soft-updates) /dev/ad0s2a on /S2 (ufs, local, soft-updates) /dev/ad0s2e on /S2/usr (ufs, NFS exported, local, soft-updates) /dev/ad0s3e on /usr (ufs, NFS exported, local, soft-updates) /dev/ad0s3g on /var (ufs, local, soft-updates) /dev/ad0s3h on /common (ufs, NFS exported, local, soft-updates) procfs on /proc (procfs, local) /dev/md10c on /tmp (ufs, local, soft-updates) m147[5] sudo boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x00 73: 0: 1 0xa5349:239:63 1103760 4188240 2 0x00350: 0: 1 0xa5626:239:63 5292000 4188240 3 0x80627: 0: 1 0xa5 1023:239:63 9480240 29589840 4 0x00 0: 1: 1 0xa0 72:239:63 63 1103697 version=1.0 drive=0x80 mask=0x7 ticks=182 options=nopacket,update,nosetdrv default_selection=F3 (Slice 3) Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On Thu, Jul 05, 2001 at 02:17:51PM -0700, Matthew Jacob wrote: David claimed he would upgrade beast at some point- but he's pretty busy. Acutally out of the state on a WRS forced vacation. :-( 1. If I had the authority to do so, I'd drive over to Concord and do it. I can do that next week some time. beast is actually now in an Exodus facility. Not that updating Beast would be the most productive thing considering how totally unusable 5-CURRENT is on Alpha right now. Actually, you can work around this if you set enough environment variables, but it certainly is annoying to do. What is so hard with ``make -m /home/kris/mk''? In fact I would say that *no one* should be doing warnings cleanup with testing on the Alpha or sparc64 -- the i386 lets people change sloppy code to be even more sloppy and get away with it. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On Wed, Jul 04, 2001 at 08:53:59AM +0200, Dag-Erling Smorgrav wrote: Not normal, except by dimwits who add WARNS?= 2 w/o checking. Now, would it really have been so hard to just send (or even commit) a patch that declares len as a size_t rather than an unsigned int, instead of calling people names? I don't have a frickin' Alpha, you dimwit, and beast is so out of date it's useless. Send me a working 1. if you cannot test properly don't do WARNS fixing. find something else to work on 2. you have suffient diskspace to check out things into and `make -m /home/des/src/share/mk' is easly enough you should be able to handle it Alpha with at least 64 MB RAM and 4 GB disk, then we'll talk. Or go buy one with your own money like a lot of us did, so we could test things w/o fcking them up. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
Well, unless implicit pointer-to-int conversions have suddenly become fatal, it blew up on something that just got fixed (I went to commit the fix and found that someone else had already done so in the last 12 hours). The world build has been restarted and is running again. - Jordan From: Kris Kennaway [EMAIL PROTECTED] Subject: Re: chgrp broken on alpha systems Date: Thu, 5 Jul 2001 16:22:27 -0700 On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote: Since David's busy, I'm working on it now. Just some build issues to be worked out since warnings were made fatal recently. What problems? There shouldn't be any fatalities from warnings unless people have marked something with WARNS prematurely. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On 05-Jul-01 Kris Kennaway wrote: On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote: Since David's busy, I'm working on it now. Just some build issues to be worked out since warnings were made fatal recently. What problems? There shouldn't be any fatalities from warnings unless people have marked something with WARNS prematurely. Err, that's exactly the problem. People have turned on WARNS= after only testing on i386 and thus breaking the alpha when alpha-specific (or P64-specific) warnings turn up. Kris -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On 06-Jul-01 Jordan Hubbard wrote: Well, unless implicit pointer-to-int conversions have suddenly become fatal, it blew up on something that just got fixed (I went to commit the fix and found that someone else had already done so in the last 12 hours). The world build has been restarted and is running again. Matt Jacob usually steps in and fixes breakages on the alpha. At the minimum, people should be either testing the build on all archs, or asking for someone else to review the patch on archs they don't have available (this last is a more feasible means as we add more and more archs, we can't expect everyone to own a x86, sparc64, ppc, alpha, and ia64). In the WARNS= case, another workable method would be to commit the warning fixes but don't commit the actual WARNS= change until the build has been verified on all archs. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: Kernel thread system nomenclature.
Jason Evans wrote: On Mon, Jul 02, 2001 at 02:16:16PM -0700, Julian Elischer wrote: Almost all of the current 'proc' pointers being passed around the system in syscalls will be changed to the #4 item. In addition, most accesses to curproc would point to a curthread (curr-#4) or a curr#3, so the names selected will be used a lot. The exctent of these edits almost makes it worthwhile to call the #4 item 'struct proc' as the size of the diff would be MASSIVLY reduced.. :-). (everyhting to do with sleeping, blocking, and waking up would avoid changes, and everywhere a syscall passes down struct proc *p would avoid changes. I think there is a clear argument for #1 to be struct proc. I don't much care what #2, #3, and #4 are called. I am of the rather strong opinion that calling #3/#4 struct proc is a bad idea in the long run. Yes, it would reduce the diffs, but it would be terribly confusing to those who weren't versed with the development history of KSEs. Also keep in mind that netbsd use 'struct lwp *' for #3/#4 (SA has these combined into one entity). If there is an easy way to not be gratuitously different I think it would be worth it. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KLD-module(dir) naming conventions
On Thu, Jul 05, 2001 at 10:12:50AM +0200, Michael Reifenberger wrote: Hi, it seems to me that most existing if_* modul-directories are named in an inconstant way. FE: if_ti.c - /sys/modules/ti- if_ti.ko if_fxp.c - /sys/modules/fxp - if_fxp.ko ... but ... if_ef.c - /sys/modules/if_ef - if_ef.ko Whats desired? They should have been if_* or possiably if/*, but since current plans are to take src/sys/modules out back and shoot it, there's probably no point in fixing the problem. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: chgrp broken on alpha systems
John Baldwin [EMAIL PROTECTED] writes: On 06-Jul-01 Jordan Hubbard wrote: Well, unless implicit pointer-to-int conversions have suddenly become fatal, it blew up on something that just got fixed (I went to commit the fix and found that someone else had already done so in the last 12 hours). The world build has been restarted and is running again. Matt Jacob usually steps in and fixes breakages on the alpha. At the minimum, people should be either testing the build on all archs, or asking for someone else to review the patch on archs they don't have available (this last is a more feasible means as we add more and more archs, we can't expect everyone to own a x86, sparc64, ppc, alpha, and ia64). No, but I think it's reasonable to expect that we can get some test/build boxes for these arches like we have beast for the Alpha. I'm curious how NetBSD does this. We got the WARNS stuff from them, and they have a lot more arches than we plan on in the foreseeable future. Kris? In the WARNS= case, another workable method would be to commit the warning fixes but don't commit the actual WARNS= change until the build has been verified on all archs. This doesn't work. The point of WARNS, as I see it anyway, is not to scrub the tree so that `make buildworld` produces less warning output. The point is that people who are modifying programs are less likely to introduce bugs if warnings as treated as errors (presumably, the compile outputs good warnings that actually help find bugs). The above (your idea) works when WARNS= is set the first time, but not when a program with WARNS set is modified. This, I think, is the real problem; it isn't a problem to test on all arches when you *first* set WARNS. The problem is somebody making a small change to the program later. They may not even know WARNS is set; their code didn't trigger warnings on their test box, so they think it's okay. Furthermore, this makes it harder for non-committers to submit changes; at least committers have potential access to the other arches (e.g., beast). I guess what I'm saying is that we might want to rethink how we use WARNS. It'd be nice if the tree would compile warning-free on all arches imaginable, but this simply isn't going to happen. Perhaps it makes sense to set NO_WERROR by default in a buildworld so that causing a warning on some arch isn't considered as bad as breaking world (this is less important on -current than it is on -stable). Kris already said that NO_WERROR would be the default in -stable, but it may even makes sense in -current; those developers that have a few spare minutes can unset it when they build world, and fix the warnings (or errors, now) as they encounter them. This has the advantage of making less people angry, and keeping the benifit of WARNS (i.e., finding bugs before they turn into a multitude of PRs). Thoughts? Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On Thu, Jul 05, 2001 at 06:00:25PM -0700, John Baldwin wrote: On 05-Jul-01 Kris Kennaway wrote: On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote: Since David's busy, I'm working on it now. Just some build issues to be worked out since warnings were made fatal recently. What problems? There shouldn't be any fatalities from warnings unless people have marked something with WARNS prematurely. Err, that's exactly the problem. People have turned on WARNS= after only testing on i386 and thus breaking the alpha when alpha-specific (or P64-specific) warnings turn up. There have been one or two instances of that, but they've all been quickly corrected, and in fact it sounds like Jordan's was one of those. It sounded like he was talking about further, continuing problems beyond this. Yes, people need to be more careful when enabling WARNS and not do it until they've positively tested it on alpha. Kris PGP signature
Re: chgrp broken on alpha systems
On Thu, Jul 05, 2001 at 06:54:45PM -0700, Dima Dorfman wrote: Matt Jacob usually steps in and fixes breakages on the alpha. At the minimum, people should be either testing the build on all archs, or asking for someone else to review the patch on archs they don't have available (this last is a more feasible means as we add more and more archs, we can't expect everyone to own a x86, sparc64, ppc, alpha, and ia64). No, but I think it's reasonable to expect that we can get some test/build boxes for these arches like we have beast for the Alpha. I'm curious how NetBSD does this. We got the WARNS stuff from them, and they have a lot more arches than we plan on in the foreseeable future. Kris? I don't know how NetBSD deal with it. I guess what I'm saying is that we might want to rethink how we use WARNS. It'd be nice if the tree would compile warning-free on all arches imaginable, but this simply isn't going to happen. Perhaps it makes sense to set NO_WERROR by default in a buildworld so that causing a warning on some arch isn't considered as bad as breaking world (this is less important on -current than it is on -stable). Kris already said that NO_WERROR would be the default in -stable, but it may even makes sense in -current; those developers that have a few spare minutes can unset it when they build world, and fix the warnings (or errors, now) as they encounter them. This has the advantage of making less people angry, and keeping the benifit of WARNS (i.e., finding bugs before they turn into a multitude of PRs). My thought has always been that if it becomes too troublesome to prevent people introducing fatal warnings on some architectures, we can enable NO_WERROR for that arch. This will also probably be needed during the porting phase to new architectures which may produce different kinds of gcc warnings. I guess it's up to the alpha developers to decide if the rate of warnings being introduced is annoying enough to warrant NO_WERROR on their platform, or if it's better to just fix the (usually trivial) warnings as they come up, so the code stays clean and portable and doesn't get left behind. Kris PGP signature
Re: chgrp broken on alpha systems
On 06-Jul-01 Dima Dorfman wrote: In the WARNS= case, another workable method would be to commit the warning fixes but don't commit the actual WARNS= change until the build has been verified on all archs. This doesn't work. The point of WARNS, as I see it anyway, is not to scrub the tree so that `make buildworld` produces less warning output. The point is that people who are modifying programs are less likely to introduce bugs if warnings as treated as errors (presumably, the compile outputs good warnings that actually help find bugs). The above (your idea) works when WARNS= is set the first time, but not when a program with WARNS set is modified. This, I think, is the real problem; it isn't a problem to test on all arches when you *first* set WARNS. The problem is somebody making a small change to the program later. They may not even know WARNS is set; their code didn't trigger warnings on their test box, so they think it's okay. Furthermore, this makes it harder for non-committers to submit changes; at least committers have potential access to the other arches (e.g., beast). Good point. However, I would argue that we don't need to just lower the standard and say its ok for warnings to persist. These things can be fixed to work on all archs. One thing that would help is for people to be a little less uptight and when a bogon pops up on one arch just fix it and go on. Yelling and screeching about it doesn't really accomplish anything, and people who are more familiar with the arch are in a much better position to fix the little bogon's (size_t instead of int) anyways. Basically, some people take offense every time the alpha build breaks and spend more time complaining about it then it would take to just commit the simple fix. Recently, this trend has started changing somewhat (Matt does commit lots of quick fixes for simple build breakages nowadays) and I think that just realising that developers have limited time to spend on this project (volunteers after all) and being a little more flexible is probably the most practical solution. It is current after all. By the time changes get MFC'd, they will have surived all the archs and won't break stable. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On Thu, Jul 05, 2001 at 05:38:31PM -0700, David O'Brien wrote: What is so hard with ``make -m /home/kris/mk''? That's actually not one of the hoops you need to jump through on beast -- I think I got someone to install the new mk files already. The main hoops are related to stale /usr/include and so forth. In fact I would say that *no one* should be doing warnings cleanup with without? testing on the Alpha or sparc64 -- the i386 lets people change sloppy code to be even more sloppy and get away with it. Kris PGP signature
Re: KLD-module(dir) naming conventions
On Thu, 5 Jul 2001, Michael Reifenberger wrote: Hi, it seems to me that most existing if_* modul-directories are named in an inconstant way. FE: if_ti.c - /sys/modules/ti- if_ti.ko if_fxp.c - /sys/modules/fxp - if_fxp.ko ... but ... if_ef.c - /sys/modules/if_ef - if_ef.ko Whats desired? if_foo.c - /sys/modules/foo - foo.ko. There is no driver named if_foo. While I'm wishing: KLD - LKM. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
Yes, I've actually been massaging a few of those- glad somebody's on it. I'll come on out to Concord if you you need a hand It's sometimes hard to keep -current up on an alpha long enough for a complete buildworld On Thu, 5 Jul 2001, Jordan Hubbard wrote: Since David's busy, I'm working on it now. Just some build issues to be worked out since warnings were made fatal recently. - Jordan From: Matthew Jacob [EMAIL PROTECTED] Subject: Re: chgrp broken on alpha systems Date: Thu, 5 Jul 2001 14:17:51 -0700 (PDT) David claimed he would upgrade beast at some point- but he's pretty busy. 1. If I had the authority to do so, I'd drive over to Concord and do it. I can do that next week some time. 2. If I had 144KBit DSL, I'd pay the extra power bills and leave up a PC164 at Feral all the time for people to do this. 3. If I had the ability to sweet talk the NASA/Ames folks, I'd leave a machine there up all the time. If beast can't be upgraded soon, and #1 can't happen, I will make #2 happen. I have two PC164s- and one could just be left up all the time. On Thu, 5 Jul 2001, Kris Kennaway wrote: On Thu, Jul 05, 2001 at 11:00:09AM +0200, Dag-Erling Smorgrav wrote: Matthew Jacob [EMAIL PROTECTED] writes: it's just the same old same old refrain of beast is broken or oh well, etc. etc. etc but yer right, insulting does no good. I beg too much hard cider at dinner. It makes the veins in the forehead swell and makes one impatient. I have no problem with that :) And beast isn't broken, it's just that its bsd.*.mk files are too old to test WARNS patches. Actually, you can work around this if you set enough environment variables, but it certainly is annoying to do. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On Thu, 5 Jul 2001, Kris Kennaway wrote: On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote: Since David's busy, I'm working on it now. Just some build issues to be worked out since warnings were made fatal recently. What problems? There shouldn't be any fatalities from warnings unless people have marked something with WARNS prematurely. ROTFLH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
Perhaps what we really need- and this is really a toolchain issues- is a compiler that is just as stringent on i386 as on alpha? I dunno- there used to be a flag to lint that would worn about non-portable size casts. Is there a gcc flag that would cover most of the heavy lifting for this on i386? I'm really well aware that people don't always have the time to test compile each micro change. I'm also heavily aware that groups like NetBSD have a mindset that makes them avoid such problems to begin with. Few (yes, no insult intended, but, yes, Few) developers in FreeBSD really understand this except maybe at a vague intellectual level. I'm not sure how we can get there. Insults don't work- even though I certainly fire off too many salvos of them myself and am hardly in a position to be sanctimonious on this topic. This is a very complicated subject. It isn't just a cross-architectural issue. It's also a multi-timezone, no real design review, fix it quickly ex-poste type of problem. The same stuff happens *within* an architecture. Many companies have solved this type of problem by requiring proof of complete builds (and cstyle too) prior to committal (Sun) to a parent tree. I don't see that happening here. Nightly builds help. Legato and Auspex and other places I've worked- instituting a nightly build with email to everyone helps keep people at least *aware* of the breakage. But this is not quite pragmatic for a multi-timezone devloper base as we have because, like a WAN, the tree should probably be assumed to always be in transition. So- I'm not sure if institutional process really helps us here. Hence, we probably need some beefier tool support. Maybe we really should get serious about at least kernel LINT again. And this, btw, is just to check the syntax. The *semantics* of what we change is quite different. I fixed Matt Dillon's vm_zoneidle boo-boo in 15 minutes (12 of which waiting for a response on the breakage). It took about 2 hours this morning of boot/crash/fix/boot/crash/fix to actually sort out the semantics. I would suggest that at least the following might be helpful: a) Send changes to audit@ if they're major. b) *try* at least to compile on more than one arch - ask someone for help if you don't have access. Note that Bosko's changes were checked by me for alpha- that was a good way for this to work. Note that Matt's VM changes were checked by me, after things didn't work (or compile) any more. That's not such a good way for these things to happen. When things are a broken- and not just s cvsup timing issue, I intend to try and do the following: Send mail to -current stating apparent breakage State whether I intend to try and fix it myself or not If the responsible party for the breakage is known, they will be directly addressed also. I'll try not to be irritated. I just want the problem to go away. If the timing of the breakage is such that I'll miss my only window for working on Freebsd-Alpha for several days (as has happened about 7 times in the last year), so be it. The same issue will arrive for ia64 and sparc64, too. -matt On Thu, 5 Jul 2001, David O'Brien wrote: On Thu, Jul 05, 2001 at 02:17:51PM -0700, Matthew Jacob wrote: David claimed he would upgrade beast at some point- but he's pretty busy. Acutally out of the state on a WRS forced vacation. :-( 1. If I had the authority to do so, I'd drive over to Concord and do it. I can do that next week some time. beast is actually now in an Exodus facility. Not that updating Beast would be the most productive thing considering how totally unusable 5-CURRENT is on Alpha right now. Actually, you can work around this if you set enough environment variables, but it certainly is annoying to do. What is so hard with ``make -m /home/kris/mk''? In fact I would say that *no one* should be doing warnings cleanup with testing on the Alpha or sparc64 -- the i386 lets people change sloppy code to be even more sloppy and get away with it. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On Thu, Jul 05, 2001 at 08:07:40PM -0700, Matthew Jacob wrote: On Thu, 5 Jul 2001, Kris Kennaway wrote: On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote: Since David's busy, I'm working on it now. Just some build issues to be worked out since warnings were made fatal recently. What problems? There shouldn't be any fatalities from warnings unless people have marked something with WARNS prematurely. ROTFLH *sigh* Matt, this isn't helping: if you have something meaningful to say here, then please say it. In case it's slipped you by, people are concerned about improving the quality of code on the Alpha -- I don't own one and probably never will, but I (and a number of other i386 people) have been trying to do our bit to improve portability by fixing warnings and cast mismatches. Or I could go back and do other things and leave you Alpha people alone to bitch and complain amongst yourselves about how no-one cares about the FreeBSD/Alpha port. Maybe we're going about it the wrong way -- this is the discussion we're trying to have in this thread. Your attention and comments would be appreciated, if you care to give them. Kris PGP signature
Re: chgrp broken on alpha systems
On Thu, 5 Jul 2001, Kris Kennaway wrote: On Thu, Jul 05, 2001 at 08:07:40PM -0700, Matthew Jacob wrote: On Thu, 5 Jul 2001, Kris Kennaway wrote: On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote: Since David's busy, I'm working on it now. Just some build issues to be worked out since warnings were made fatal recently. What problems? There shouldn't be any fatalities from warnings unless people have marked something with WARNS prematurely. ROTFLH *sigh* Matt, this isn't helping: if you have something meaningful to say here, then please say it. In case it's slipped you by, people are concerned about improving the quality of code on the Alpha -- I don't own one and probably never will, but I (and a number of other i386 people) have been trying to do our bit to improve portability by fixing warnings and cast mismatches. Or I could go back and do other things and leave you Alpha people alone to bitch and complain amongst yourselves about how no-one cares about the FreeBSD/Alpha port. Maybe we're going about it the wrong way -- this is the discussion we're trying to have in this thread. Your attention and comments would be appreciated, if you care to give them. Did you read my other mails? I doesn't appear that you have. Or you didn't understand them. I was laughing because, yes, WARNS was turned on prematurely which killed things. I have to laugh. Sorry if you don't that helps. S'long then. I've no more time for the likes of you. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
I have to laugh. Sorry if you don't that helps. S'long then. I've no more time for the likes of you. *rolls eyes* Man, some people are hard to work in a team with. You guys are still trying to pass this off as a team?? *boggle* gh (Yeah yeah, unproductive..but what part of this thread /has/ been?) Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
On Thu, 5 Jul 2001, GH wrote: I have to laugh. Sorry if you don't that helps. S'long then. I've no more time for the likes of you. *rolls eyes* Man, some people are hard to work in a team with. You guys are still trying to pass this off as a team?? *boggle* gh (Yeah yeah, unproductive..but what part of this thread /has/ been?) Actually, the growing realization (at least to me) that the problem probably cannot be solved except via software tools, unless the FreeBSD community gets more like the NetBSD community in terms of awareness- which can only happen if it happens. I don't know how you feel about it, but I believe that this *is* productive. We can then spend a lot less time with unmet expectations, once the expecations are more realistically set, yes? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interruptable hang starting init in today's -CURRENT
Date: Thu, 5 Jul 2001 22:12:46 +0700 (NOVST) From: [EMAIL PROTECTED] start_init: trying /sbin/init DEPENDENCY NOTE: portmap will be enabled to support NFS Entropy harvesting: interrupts ethernet point_to_point Leaving the system alone, it will apparently sit there (staying fairly busy, based on the speed of the fan -- this is my laptop) indefinitely. I see analogous situation on my -CURRENT system (this is 'uname -a' of it: FreeBSD wint.itfs.nsk.su 5.0-CURRENT FreeBSD 5.0-CURRENT #2:\ Thu Jul 5 16:04:53 NOVST 2001\ [EMAIL PROTECTED]:/scratch/obj/usr/src/sys/WINTS i386) In my case the reason for Hang is in the 'sysctl -a' command (/dev/random feeding one in /etc/rc). This command (or even 'sysctl net.inet.accf') runs endlessly ;-( OK; I got today's -CURRENT built and running: FreeBSD m147.whistle.com 5.0-CURRENT FreeBSD 5.0-CURRENT #60: Thu Jul 5 09:27:49 PDT 2001 [EMAIL PROTECTED]:/common/C/obj/usr/src/sys/LAPTOP_30W i386 but it exhibits the same hanging. And sure enough, sysctl -a hangs; here's that last part of its output before it does: net.inet.tcp.local_slowstart_flightsize: 65535 net.inet.tcp.newreno: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.pcbcount: 27 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.msl: 3 net.inet.tcp.always_keepalive: 1 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.log_in_vain: 0 net.inet.udp.blackhole: 0 net.inet.accf.unloadable: 0 ^C A -CURRENT kernel as recent as 2 days ago does not exhibit this, and the problem showed up yesterday. (My previous message has details such as message dmesg logs and CVSup history.) I'll be hunting for likely commits, though I wouldn't object if someone else beats me to it :-) Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: chgrp broken on alpha systems
Actually, the growing realization (at least to me) that the problem probably cannot be solved except via software tools, unless the FreeBSD community gets more like the NetBSD community in terms of awareness- which can only happen if it happens. I don't know how you feel about it, but I believe that this *is* productive. We can then spend a lot less time with unmet expectations, once the expecations are more realistically set, yes? Absolutely, I agree entirely that Something Is Wrong and that the FreeBSD development community would benefit from some modifications to policy and more importantly to attitude The general realization is most productive, but you have to go around all the bickering. Nothing really. We now return to regularly scheduled programming. gh -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Another GNU ld(1) bug
In article [EMAIL PROTECTED], Maxim Sobolev [EMAIL PROTECTED] wrote: It turns that ld(1) in -current has another nasty bug. I noticed it when was doing an upgrade for the games/bomberinstinct port. Something is wrong with registering dependencies on shared libraries - following trace shows the problem (notice bogus crtn.o entry): Yep, the same bug shows up in the uic program which is built by the qt23 port. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: softupdates on /
On Thu, 5 Jul 2001, Dan Nelson wrote: :In the last episode (Jul 05), Benjamin P. Grubin said: : As of a month ago or so, there was some discussion that concluded it : was unsafe to enable softupdates on a root partition. Is it safe to : go back in the water there, now? : :The 2 drawbacks with SU are : :1 - You can't immediately reuse the space occupied by a file you just :deleted; this may bite you if you do an installworld and don't have :20MB free on /. when it comes to installing /sbin, you need 18MB :for the new binaries, but you can't reuse the 18MB for the :just-deleted binaries. I've dodged that problem by SIGSTOPing installworld a couple times during the /sbin install, waiting for softupdates to catchup, and then SIGCONTing it. That's a pain; it's ugly, but it does work. Easier than a reboot, sometimes. -- [EMAIL PROTECTED] Bipedalism is only a fad. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: softupdates on /
In the last episode (Jul 06), David Scheidt said:
On Thu, 5 Jul 2001, Dan Nelson wrote:
:In the last episode (Jul 05), Benjamin P. Grubin said:
: As of a month ago or so, there was some discussion that concluded it
: was unsafe to enable softupdates on a root partition. Is it safe to
: go back in the water there, now?
:
:The 2 drawbacks with SU are
:
:1 - You can't immediately reuse the space occupied by a file you just
:deleted; this may bite you if you do an installworld and don't have
:20MB free on /. when it comes to installing /sbin, you need 18MB
:for the new binaries, but you can't reuse the 18MB for the
:just-deleted binaries.
I've dodged that problem by SIGSTOPing installworld a couple times during
the /sbin install, waiting for softupdates to catchup, and then SIGCONTing
it. That's a pain; it's ugly, but it does work. Easier than a reboot,
sometimes.
My workaround when it bit me was to run a while sleep 1 ; do sync ;
done loop in another window to speed up the softupdate clock. I
suppose cranking down the kern.{file,meta,dir}delay sysctls would have
done the same thing.
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Another GNU ld(1) bug
Hi, It turns that ld(1) in -current has another nasty bug. I noticed it when was doing an upgrade for the games/bomberinstinct port. Something is wrong with registering dependencies on shared libraries - following trace shows the problem (notice bogus crtn.o entry): cc -pipe -O -mpreferred-stack-boundary=2 -march=k6 -I/usr/local/include -I/usr/l ocal/include/SDL11 -D_REENTRANT -DDIR=\/usr/local/share/BomberInstinct\ -L/usr /local/lib -o bi main.o sprites.o niveaux.o pouvoirs.o evenements.o options.o so n.o intro.o SFont.o gamelogic.o -lSDL_mixer -lm -lSDL_mixer -L/usr/local/lib -Wl ,-rpath,/usr/local/lib -lSDL-1.1 -lc_r -lm -L/usr/local/lib -lesd -laudiofile -l m -L/usr/X11R6/lib -lX11 -lXext -lXxf86vm -lXxf86dga -lvga -laa gmake[1]: ÷ÙÈÏÄ ÉÚ ËÁÔÁÌÏÇ `/tmp/mnt/bomberinstinct/work/BomberInstinct-0.8.7/sr c' gmake[1]: ÷ÈÏÄ × ËÁÔÁÌÏÇ `/tmp/mnt/bomberinstinct/work/BomberInstinct-0.8.7' gmake[1]: ãÅÌØ `all-am' ÎÅ ÔÒÅÂÕÅÔ ×ÙÐÏÌÎÅÎÉÑ ËÏÍÁÎÄ. gmake[1]: ÷ÙÈÏÄ ÉÚ ËÁÔÁÌÏÇ `/tmp/mnt/bomberinstinct/work/BomberInstinct-0.8.7' root@big_brother# ld --version GNU ld 2.11.2 [FreeBSD] Copyright 2001 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. Supported emulations: elf_i386 root@big_brother# ldd /tmp/mnt/bomberinstinct/work/BomberInstinct-0.8.7/src/bi /tmp/mnt/bomberinstinct/work/BomberInstinct-0.8.7/src/bi: libSDL_mixer.so.2 = /usr/local/lib/libSDL_mixer.so.2 (0x28074000) libm.so.2 = /usr/lib/libm.so.2 (0x280ab000) libSDL-1.1.so.3 = /usr/local/lib/libSDL-1.1.so.3 (0x280c6000) libc_r.so.5 = /usr/lib/libc_r.so.5 (0x2810f000) libesd.so.2 = /usr/local/lib/libesd.so.2 (0x2812d000) libaudiofile.so.0 = /usr/local/lib/libaudiofile.so.0 (0x28135000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x28153000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x281ef000) libvga.so.1 = /usr/local/lib/libvga.so.1 (0x281fb000) libaa.so.1 = /usr/local/lib/libaa.so.1 (0x28263000) libc.so.5 = /usr/lib/libc.so.5 (0x2827a000) crtn.o (0x0) libvorbisfile.so.0 = /usr/local/lib/libvorbisfile.so.0 (0x28328000) libvorbis.so.0 = /usr/local/lib/libvorbis.so.0 (0x2832d000) libsmpeg.so.1 = /usr/local/lib/libsmpeg.so.1 (0x28342000) libXThrStub.so.6 = /usr/X11R6/lib/libXThrStub.so.6 (0x283a1000) libncurses.so.5 = /usr/lib/libncurses.so.5 (0x283a3000) libogg.so.1 = /usr/local/lib/libogg.so.1 (0x283e4000) When I replaced /usr/libexec/elf/ld with one from the my 4-STABLE system and recompiled application the problem disappeared. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KLD-module(dir) naming conventions
In message 20010705100122.N1134-10@nihil Michael Reifenberger writes: : Hi, : it seems to me that most existing if_* modul-directories : are named in an inconstant way. : FE: : if_ti.c - /sys/modules/ti- if_ti.ko : if_fxp.c - /sys/modules/fxp - if_fxp.ko : ... : but : ... : if_ef.c - /sys/modules/if_ef - if_ef.ko : : Whats desired? The former. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KLD-module(dir) naming conventions
In message [EMAIL PROTECTED] Brooks Davis writes: : They should have been if_* or possiably if/*, but since current plans I think the current way that most of them are done (eg module/foo) is right. : are to take src/sys/modules out back and shoot it, there's probably no : point in fixing the problem. This is certainly true. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I take it alpha is broken now, yes?
ha/alpha/genassym.c ../../../vm/vm_zeroidle.c:13: opt_npx.h: No such file or directory ../../../vm/vm_zeroidle.c:17: opt_reset.h: No such file or directory ../../../vm/vm_zeroidle.c:38: machine/pcb_ext.h: No such file or directory ../../../vm/vm_zeroidle.c:39: machine/vm86.h: No such file or directory mkdep: compile failed *** Error code 1 *none* of these should be included in non-i386/pc98 code. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
