Re: gcc 2.95.2
On Tue, 16 Nov 1999 20:15:17 PST, "Rodney W. Grimes" wrote: > Something weird is going on... I can confirm Manfred's claim, I also > just build XFree86 just before the compiler change. I'm certainly not > going to cvs update right now... :-) Gentlemen, would you please use the right terminology so that we don't get confused? :-) XFree86 makes it through the ports ``build'' target just fine. It breaks in ``install''. That's why I told Manfred I wasn't seeing the problem. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 2.95.2
> On Tue, 16 Nov 1999, Manfred Antar wrote: > > > I think this is all related to the compiler update as I did a good > > build Friday or > > Saturday before the change. > > If it is, then some thing wierd is going on. Something weird is going on... I can confirm Manfred's claim, I also just build XFree86 just before the compiler change. I'm certainly not going to cvs update right now... :-) -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 2.95.2
At 09:50 PM 11/16/99 -0500, Bill Fumerola wrote: >On Tue, 16 Nov 1999, Manfred Antar wrote: > > > I think this is all related to the compiler update as I did a good > > build Friday or > > Saturday before the change. > >If it is, then some thing wierd is going on. Maybe it's something else, there might of been some other changes to the src tree that I didn't notice.My date for the last clean build of XFree86 is Saturday at midnight (with threads) The build machine was current at that point with a make world done some time Sat morning. Thanks Manfred = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 2.95.2
On Tue, 16 Nov 1999, Manfred Antar wrote: > I think this is all related to the compiler update as I did a good > build Friday or > Saturday before the change. If it is, then some thing wierd is going on. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 2.95.2
At 09:35 PM 11/16/99 -0500, Bill Fumerola wrote: >On Tue, 16 Nov 1999, Manfred Antar wrote: > > > -DDEFAULT_CONFIG=\"/usr/ > > X11R6/lib/X11/rstart/config\" -DNOPUTENV server.c > > server.c: In function `putenv': > > server.c:790: argument `s' doesn't match prototype > > /usr/include/stdlib.h:117: prototype declaration > > *** Error code 1 (continuing) > >There are a _lot_ of things broken with this port. I've already >marked it broken for the above reason. There is the /lib/cpp problem, >the -lcrypto problem, it doesn't build the servers you tell it to. > >Ugh. > >-- >- bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - >- ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - I think this is all related to the compiler update as I did a good build Friday or Saturday before the change. Thanks Manfred = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver- Okay, Okay, you win....
> On Tuesday, 16 November 1999 at 8:04:05 -0800, Matthew Jacob wrote: > > > > Too many people have objected. I didn't make my case clearly enough, > > but because enough people of have raised issues, the default won't > > be changed. > > I think this is the correct decision in the short term. In the longer > term, we should continue to discuss the matter. Absolutely, and I'll do some spec digging and hunting in the archives for my old notes about this particular problem. I'd been hunting SCSI specs when someone else on here mentioned ANSI and that jogged my memory as to where I need to go looking... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 2.95.2
On Tue, 16 Nov 1999, Manfred Antar wrote: > -DDEFAULT_CONFIG=\"/usr/ > X11R6/lib/X11/rstart/config\" -DNOPUTENV server.c > server.c: In function `putenv': > server.c:790: argument `s' doesn't match prototype > /usr/include/stdlib.h:117: prototype declaration > *** Error code 1 (continuing) There are a _lot_ of things broken with this port. I've already marked it broken for the above reason. There is the /lib/cpp problem, the -lcrypto problem, it doesn't build the servers you tell it to. Ugh. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 2.95.2
At 05:14 PM 11/16/99 -0800, Manfred Antar wrote: >At 04:50 PM 11/16/99 +0200, Sheldon Hearn wrote: > > >>On Tue, 16 Nov 1999 06:46:12 PST, Manfred Antar wrote: >> >> > Did it build for you ? >> >>Yes. >> >>Ciao, >>Sheldon. > >Ok Sheldon here are some of the Errors I get when building XFee86 with the >new compiler >A few of these : > >cc -c -O -I../.. >-I../../exports/include -DSERVERNAME=\"rstartd\" -DDEFAULT_CONFIG=\"/usr/ >X11R6/lib/X11/rstart/config\" -DNOPUTENV server.c >server.c: In function `putenv': >server.c:790: argument `s' doesn't match prototype >/usr/include/stdlib.h:117: prototype declaration >*** Error code 1 (continuing) Someone Just put a broken tag in the makefile. = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 2.95.2
At 04:50 PM 11/16/99 +0200, Sheldon Hearn wrote: >On Tue, 16 Nov 1999 06:46:12 PST, Manfred Antar wrote: > > > Did it build for you ? > >Yes. > >Ciao, >Sheldon. Ok Sheldon here are some of the Errors I get when building XFee86 with the new compiler A few of these : cc -c -O -I../.. -I../../exports/include -DSERVERNAME=\"rstartd\" -DDEFAULT_CONFIG=\"/usr/ X11R6/lib/X11/rstart/config\" -DNOPUTENV server.c server.c: In function `putenv': server.c:790: argument `s' doesn't match prototype /usr/include/stdlib.h:117: prototype declaration *** Error code 1 (continuing) cc -c -O -I../.. -I../../exports/include-DNOPUTENV util.c util.c: In function `putenv': util.c:673: argument `s' doesn't match prototype /usr/include/stdlib.h:117: prototype declaration *** Error code 1 (continuing) Many of these errors about /lib/cpp: /lib/cpp -DCONFIGDIRSPEC='"'"-I/usr/X11R6/lib/X11/config"'"' xmkmf /lib/cpp: not found And at the end I get this : Full build of Release 6.3 of the X Window System complete. Now when I try to Install the "Full Build" I get install -c proxymngr /usr/X11R6/bin/proxymngr install -c -m 0444 pmconfig /usr/X11R6/lib/X11/proxymngr/pmconfig install in programs/proxymngr done installing in programs/rstart... rm -f server.o cc -c -O -I../.. -I../../exports/include -DSERVERNAME=\"rstartd\" -DDEFAULT_CONFIG=\"/usr/ X11R6/lib/X11/rstart/config\" -DNOPUTENV server.c server.c: In function `putenv': server.c:790: argument `s' doesn't match prototype /usr/include/stdlib.h:117: prototype declaration *** Error code 1 Stop in /usr/ports/x11/XFree86/work/xc/programs/rstart. *** Error code 1 Stop in /usr/ports/x11/XFree86/work/xc/programs. *** Error code 1 Stop in /usr/ports/x11/XFree86/work/xc. *** Error code 1 Stop in /usr/ports/x11/XFree86/work/xc. *** Error code 1 Stop in /usr/ports/x11/XFree86. *** Error code 1 Stop in /usr/ports/x11/XFree86. *** Error code 1 Stop in /usr/ports/x11/XFree86. This is a build with Just the XF86SVGAServer and XF86VGA16Server plus all the security stuff xdm, Wraphelp.c, no Kerberos or Thread Thanks Manfred = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
what's changed?
Make release was working fine a week ago. The past four days I get the following error every time I try: (cd /usr/src/etc/..; install -c -o root -g wheel -m 444 COPYRIGHT /reserve/) (cd /usr/src/etc/../share/man; make makedb; ) makewhatis /reserve/usr/share/man makewhatis /reserve/usr/share/perl/man if [ -f /etc/resolv.conf ]; then cp -p /etc/resolv.conf /reserve/etc; fi cd /usr/src/release/.. && make installworld DESTDIR=/reserve NOMAN=1 cd /usr/src; PATH=/usr/obj/usr/src/tmp/sbin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/bin:/usr/obj/usr/src/tmp/usr/bin BISON_SIMPLE=/usr/obj/usr/src/tmp/usr/share/misc/bison.simple COMPILER_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/obj/usr/src/tmp/usr/bin GCC_EXEC_PREFIX=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib/ LD_LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib PERL5LIB=/reserve/usr/libdata/perl/5.00503 OBJFORMAT_PATH=/usr/obj/usr/src/tmp/usr/libexec CFLAGS="-nostdinc -O -pipe" /usr/obj/usr/src/tmp/usr/bin/make -f Makefile.inc1 reinstall objformat: not found "/usr/src/Makefile.inc1", line 961: warning: "objformat" returned non-zero status echo:No such file or directory *** Error code 1 Stop in /usr/src. *** Error code 1 What do I do wrong? I've no special settings in the Makefile that can cause this. I cvsupped and rebuilt (cvs -d co src) my own source tree from scratch. Didn't help. TIA! Marc Schneiders [EMAIL PROTECTED] [EMAIL PROTECTED] propro 11:38pm up 5 days, 11:24, load average: 2.18 2.10 2.09 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: the ps/cmdline caching
In message <[EMAIL PROTECTED]>, "Justin T. Gibbs" wri tes: >I must have missed a thread somewhere. Can I get a reference to what >this problem is? Run this on a SMP box and it will die in seconds: i=0 while [ $i -lt 200 ] do i=`expr $i + 1` ( while true ; do ps xao pid,command > /dev/null 2>&1 ; done ) & done The problem is where ps using /proc/%pid/mem grovels around in the other process address room to get hold of argv. This gets particular nasty when we have multiple copies of ps(1) running on a SMP box: First CPU: running process 100 which is a "ps -ax" currently trying to get the argument list from process 101 Second CPU: running process 101 which is a "ps -ax" currently trying to get the argument list from process 101 (or 100 for that matter). The code in procfs_mem.c has significant problems in this scenario, and rather than try to hunt them down, something we should eventually do my solution is to hang a copy of of the arg list from struct proc and use a sysctl in the kern.proc family to access it. My implementation has a sysctl variable which sets an upper limit on how many bytes we use per process for this. If this limit is exceeded, we default to the current reality, obviously the limit can be set to zero as well. For anyone wanting to work on procfs_mem, setting the sysctl to zero will revert to current behaviour so that bug is not obscured. The arguments are stored in a separate structure which is shared across fork and replaced in exec, so the overhead in struct proc itself is only a pointer, and for daemons which fork a lot of children only one copy of the arguments are stored, until they set their own with setproctitle() that is. The side effects of this change are many and varied: Plus side: 1. ps(1) runs much faster and uses far fewer resources. 2. ps(1) don't need a /proc anymore. Particular nice for chroot and jail. 3. We get access to the full command line in kernel debuggers. 4. (untested/unimplemented) /bin/ps doesn't need to be setgid kmem anymore. 5. On the long run we use less memory because we don't need to i allocate a vnode and inode for /proc/%pid/mem. (This is not implemented yet, we need to figure out how much ps(1) should use libkvm and fix it accordingly). On the minus side: 1. Memory usage, if all your process have very long commandlines. (You can limit this with the sysctl.) 2. A process which writes to argv[0] rather than use setproctitle() doesn't have the desired effect. (Setting the sysctl to zero solves this problem as well.) 3. If you never run ps(1) there is a epsilon sized overhead in exec(2). (You can make that a epsilon-squared sized overhead by setting the sysctl to zero.) So expect to hear a happy Paul Saab sing our praise once again and expect to see my commit to -current in a few moments. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!
Re: FreeBSD 4.0 SCSI Tape Driver- Okay, Okay, you win....
On Tue, 16 Nov 1999, Greg Lehey wrote: > On Tuesday, 16 November 1999 at 8:04:05 -0800, Matthew Jacob wrote: > > > > Too many people have objected. I didn't make my case clearly enough, > > but because enough people of have raised issues, the default won't > > be changed. > > I think this is the correct decision in the short term. In the longer > term, we should continue to discuss the matter. Yes, well, I was driven by the coming of 4.0 My *original* plans for 4.0 was to do a complete rewrite of the tape driver using the HP sponsored TAPEALERT initiative, but I've had only a fraction of the time available. So, what with fixing some bugs, trying to make sure that subdevices come back with latchable settings, that'll probably be it for tape in 4.0. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver- Okay, Okay, you win....
On Tuesday, 16 November 1999 at 8:04:05 -0800, Matthew Jacob wrote: > > Too many people have objected. I didn't make my case clearly enough, > but because enough people of have raised issues, the default won't > be changed. I think this is the correct decision in the short term. In the longer term, we should continue to discuss the matter. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Adding soundcards to newpcm
On Wed, 17 Nov 1999, Daniel C. Sobral wrote:
> Well, I finally decided to try to get my sound card working again.
> It is not detected as a PNP device, but rather as a motherboard
> resource using PNPBIOS. It is supposed to be an ESS1869 and, indeed,
> I use ESS drivers on Windows. But Compaq obviously decided to lay
> it's fingerprints on the poor thing. Here is the (relavant parts of)
> dmesg:
>
> So, the question is... how do I get the logical identifier for it?
> pnpinfo doesn't show anything.
Use this program. It translates to/from EISAIDs.
#include
#include
int
main(int argc, char** argv)
{
u_int32_t id;
if (argc != 2)
exit(1);
if (!strncmp(argv[1], "0x", 2)) {
id = strtol(argv[1] + 2, NULL, 16);
#define B0(n) (((n) >> 0) & 0xff)
#define B1(n) (((n) >> 8) & 0xff)
#define B2(n) (((n) >> 16) & 0xff)
#define B3(n) (((n) >> 24) & 0xff)
printf("%c%c%c%02x%02x\n",
((B0(id) & 0x7c) >> 2) + 64,
(((B0(id) & 0x03) << 3) | ((B1(id) & 0xe0) >> 5)) + 64,
(B1(id) & 0x1f) + 64, B2(id), B3(id));
} else {
#define PNP_HEXTONUM(c) ((c) >= 'a' \
? (c) - 'a' + 10 \
: ((c) >= 'A' \
? (c) - 'A' + 10\
: (c) - '0'))
#define PNP_EISAID(s) \
s[0] - '@') & 0x1f) << 2) \
| (((s[1] - '@') & 0x18) >> 3) \
| (((s[1] - '@') & 0x07) << 13)\
| (((s[2] - '@') & 0x1f) << 8) \
| (PNP_HEXTONUM(s[4]) << 16) \
| (PNP_HEXTONUM(s[3]) << 20) \
| (PNP_HEXTONUM(s[6]) << 24) \
| (PNP_HEXTONUM(s[5]) << 28))
printf("0x%08x\n", PNP_EISAID(argv[1]));
}
return 0;
}
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Tue, Nov 16, 1999 at 07:29:35PM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Pierre Beyssac writes: > >Since in_cksum is used in several places (there's another optimized > Isn't there one in libalias already ? Right. I missed it because it's called PacketAliasInternetChecksum()... -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
In message <[EMAIL PROTECTED]>, Pierre Beyssac writes: >Since in_cksum is used in several places (there's another optimized >copy in libstand), a cleaner solution would be to put it in some >library. Isn't there one in libalias already ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Mon, Nov 15, 1999 at 05:59:23PM -0800, Kris Kennaway wrote: > On Tue, 16 Nov 1999, Pierre Beyssac wrote: > > I've checked, the answer is no: apparently, in_cksum() in routed/rdisc.c > > is only called in two places, both with an even size. > > Can it hurt to pre-emptively fix it anyway in case some future change > pulls the rug out from underneath? We could, but since the danger is purely theoretical for now (and probably will stay that way forever), I don't see any advantage in cluttering up the code. Since routed is sometimes sync'ed from external sources, it would only make life harder for the people doing the merges. Plus, everyone steals in_cksum from ping, not from routed (at least, that's what I do :-) Since in_cksum is used in several places (there's another optimized copy in libstand), a cleaner solution would be to put it in some library. -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps -e
On Monday, 15 November 1999 at 16:27:12 -0800, Matthew Dillon wrote: > :>Matthew> Why don't we get rid of the 'e' option to ps while we > :>Matthew> are at it considering how much of a security hole it is. > :> > :>I wouldn't nuke it completely. Make -e a noop unless the real uid ps > :>is running with matches the effective uid of the process being reported. > :>And if ps is invoked with a real uid of 0, -e works as it does now. > : > :I'd favor something like this. The unixes I am most used to did not > :have '-e' as an option, and I had two immediate reactions when I found > :freebsd's did: > :1) wow, this is great for debugging a problem I'm having > :2) yikes, what a security exposure! (I have some scripts > : where a password is passed from one script to another > : one via an environment variable...) > > Yes, or by 'root'. Personally, I would like to see the option removed > entirely. I don't think a half-measure would improve the security > problem much. > > :So, I'd like to have it for debugging my own processes, but > :... > :Garance Alistair Drosehn = [EMAIL PROTECTED] > > gdb. > > I shudder to think that people might actually start depending on this > non-feature. Better for it to just go away. Looks like another case for a config knob. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Adding soundcards to newpcm
Well, I finally decided to try to get my sound card working again. It is not detected as a PNP device, but rather as a motherboard resource using PNPBIOS. It is supposed to be an ESS1869 and, indeed, I use ESS drivers on Windows. But Compaq obviously decided to lay it's fingerprints on the poor thing. Here is the (relavant parts of) dmesg: unknown0: at port 0xcf8-0xcff on isa0 unknown1: at port 0x80,0x22-0x24,0x92,0x370-0x371,0xec-0xef,0x40b,0x4d6,0x480-0x48f iomem 0xfffc-0x on isa0 unknown2: at iomem 0-0x9,0xe-0xf,0x10-0x5ff on isa0 unknown3: at port 0-0xf,0x81-0x8f,0xc0-0xdf drq 4 on isa0 unknown: can't assign resources unknown4: at port 0x41-0x44 irq 0 on isa0 unknown5: at port 0x70-0x71 irq 8 on isa0 unknown: can't assign resources unknown6: at port 0xf0-0xff irq 13 on isa0 unknown: can't assign resources unknown7: at port 0x220-0x22f,0x388-0x38b,0x300-0x301 irq 5 drq 0,1 on isa0 ^^^ obviously... unknown: can't assign resources unknown8: at port 0x800-0x807 on isa0 ^^^ unknown9: at port 0x201 on isa0 ^^^ though it seems they did not care about other capabilities of the chipset... unknown: can't assign resources unknown10: at port 0x378-0x37f irq 7 on isa0 unknown: can't assign resources unknown: can't assign resources unknown11: at port 0x3e0-0x3e1 on isa0 So, the question is... how do I get the logical identifier for it? pnpinfo doesn't show anything. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "Then again maybe not going to heaven would be a blessing. Relkin liked a certain amount of peace and harmony, since there'd been a pronounced shortage of them in his own life; however, nothing but peace and harmony, forever and forever? He wasn't sure about that. And no beer? Very dubious proposition." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BIND update
So wouldn't be the impact if a server was compromized in the absence of an available fix :) At 02:46 PM 11/16/99 +0800, Peter Wemm wrote: >Ben Rosengart wrote: > > On Mon, 15 Nov 1999, Forrest Aldrich wrote: > > > > > Will we be updating 4.0-current to the latest BIND-8.22-P5? > > > > Or -stable for that matter? I believe these changes are eminently > > qualified, being bugfixes. > >The changes are most definately not "just" bugfixes. The impact is rather >large. > >Cheers, >-Peter >-- >Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm0 is not found: "unknown0:"
Phil Regnauld writes: | I was running a kernel from end of august, and everything worked | fine (IBM PC 300 PL, PII-350, 128 MB RAM, built-in audio): | | Oct 5 13:28:29 aylee /kernel: pcm1 (CS423x/Yamaha/AD1816 sn 0x) at |0x530-0x537 irq 5 drq 1 flags 0x13 on isa | | Since make world last week: | | unknown0: at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 | unknown1: on isa0 | unknown2: at port 0x120-0x127 on isa0 Apply this patch in /sys/dev/pcm/isa Don't know why it is reporting 0x0001630e instead of 0x630e I'm using pcm with pnp. Doug A. Index: mss.c === RCS file: /cvs/freebsd/src/sys/dev/pcm/isa/mss.c,v retrieving revision 1.31 diff -c -r1.31 mss.c *** mss.c 1999/10/12 21:35:45 1.31 --- mss.c 1999/11/15 19:50:09 *** *** 1268,1274 else if (id == 0x3200630e) s = "CS4232"; else s = "Unknown CS"; break; ! case 0x2100a865: /* YMH0021 */ if (id == 0x2000a865) s = "Yamaha SA2"; else if (id == 0x3000a865) s = "Yamaha SA3"; --- 1268,1277 else if (id == 0x3200630e) s = "CS4232"; else s = "Unknown CS"; break; ! case 0x0001630e: /* CSC0100 */ ! if (id == 0x2500630e) s = "CS4235"; ! else s = "Unknown CS"; ! break; case 0x2100a865: /* YMH0021 */ if (id == 0x2000a865) s = "Yamaha SA2"; else if (id == 0x3000a865) s = "Yamaha SA3"; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver- Okay, Okay, you win....
Too many people have objected. I didn't make my case clearly enough, but because enough people of have raised issues, the default won't be changed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world this morning.
On Tue, 16 Nov 1999, Edwin Culp wrote: > /usr/src/games/larn/monster.c: In function `hitm': > /usr/src/games/larn/monster.c:856: syntax error before `amt' My first breakage of world, how neat. Thanks to Marcel for fixing what was the result of me having too many local copies of src/games on my laptop and checking one and committing another. Sorry -CURRENT folks.. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - PS. Sorry wpaul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world this morning.
On Tue, 16 Nov 1999, Edwin Culp wrote: > Just looking at the results of a make world from a cvsup at about 4:40 > PST. > > ed > > /usr/obj/usr/src/tmp/usr/include/sys/ttydev.h:60: warning: `B115200' > redefined > /usr/obj/usr/src/tmp/usr/include/termios.h:227: warning: this is the > location of the previous definition > cc -nostdinc -O -pipe -DBSD -DVER=12 -DSUBVER=0 -DNONAP -DUIDSCORE > -fwritable-strings -I/usr/obj/usr/src/tmp/usr/include -c > /usr/src/games/larn/monster.c > /usr/src/games/larn/monster.c: In function `hitm': > /usr/src/games/larn/monster.c:856: syntax error before `amt' > *** Error code 1 > > Stop in /usr/src/games/larn. > *** Error code 1 Yep - same here. One other problem I had is that make world failed when I used: make -j 3 -DNOPROFILE world It bombed out somewhere near the beginning of make world when gcc was being built. When I eliminated the parallel build (make -DNOPROFILE world), it got further into the build, but bombed out at the point you describe. I was able to continue on by doing make -j 3 -DNOCLEAN -DNOGAMES -DNOPROFILE world - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Make world this morning.
Just looking at the results of a make world from a cvsup at about 4:40 PST. ed /usr/obj/usr/src/tmp/usr/include/sys/ttydev.h:60: warning: `B115200' redefined /usr/obj/usr/src/tmp/usr/include/termios.h:227: warning: this is the location of the previous definition cc -nostdinc -O -pipe -DBSD -DVER=12 -DSUBVER=0 -DNONAP -DUIDSCORE -fwritable-strings -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/games/larn/monster.c /usr/src/games/larn/monster.c: In function `hitm': /usr/src/games/larn/monster.c:856: syntax error before `amt' *** Error code 1 Stop in /usr/src/games/larn. *** Error code 1 Stop in /usr/src/games. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rtc0
For some reason, after recompiling the kernel over the last few days, systat -vm no longer even shows an rtc0 device. It only shows the clk device. I know this is not supposed to happen, so can anyone give me any ideas on how to fix the problem??? = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver
> > > > Sorry, no. When you write a tape with these devices there's always a > > leading erased area. That's why if you overwrite the front a tape you > > can't skip past this area to recover data you really need. A misfeature of > > modern technology. > > Is this anchored in the standards? What about DLT? What about future > drives? I certainly wouldn't rely on anything that isn't guaranteed > to stay that way. What happens if I write a tape on FreeBSD and read > it in on System V? The whole point of what I'm trying to is to conform to other systems. I wouldn't do it if it added to interoperability problems. > > >> In your other message you talk about the driver getting 2 residuals > >> in a row, well, unless you write the 2 EOF's you won't always get that... > >> depends on if the tape drive does it automagically (which many newer > >> drives do, they write 2 eof's and backspace over 1 of them for you when > >> ever you tell them to write EOF, the drive itself uses 2 EOF's to > >> determine logical EOT :-)). > > > > I repeat what I said in other mail- can you actually show me a tape drive > > where what I propose really doesn't work? > > I think this question is the wrong way round. Apparently. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver
> > Every night, I do a partial backup, one file on tape for each file > system, about 12 in all. Subsequently I read the tape and list > contents until I hit EOT. OK, the first time I use a tape, there will > be nothing behind it. But the next time, the total length of tape > written may be shorter, so there will be data after logical EOT. How > is the program going to know where to stop? Every time you stop writing, that's EOT. You can't read past it with SCSI drives- really, no, you can't. You can seek to end of recorded data and start writing, but you can't read past where you've written to. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver
On Monday, 15 November 1999 at 9:36:16 -0800, Matthew Jacob wrote: >> >> There seems to be a great amount of confusion about the 2 EOF marks on >> tapes. It has nothing to do with physical EOT, even the 556BPI 1/2" >> tape drives on an IBM 1401 can detect physical EOT. The problem is >> with LOGICAL EOT, most tape drives do not have a logical EOT write >> command, even modern drives. So when you overwrite a tape how do you >> tell that you have gotten to the logical end of data, well, you write >> 2 EOF marks. >> >> The other thing that causes lots of folks confusion here is that some >> tape drives backspace over an EOF mark that is written, thus it gets >> real fun to put 2 EOF marks on the tape. You have to mt eof, mt fsf, >> mt eof. > > Yes, that *may* be a problem. Also, when you write two filemarks, as best > as I can tell for some hardware, this is never able to be read back as two > filemarks. > >> >> Since you do not point out how we are suppose to detect logical EOT >> on a tape I object to any elimination of dual EOF to indicate logical >> EOT. >>> >>> There already is an ioctl (and control via mt(1)) to change the default >>> eot model. There could very well also be a config option too. I'd like to >>> make the 1 Filemark at EOT the default though. I'll have to fix tcopy, >>> and I want to give some thought so that there are no compatibility >>> and interchange problems, but if those concerns are adequately covered I >>> think this is the right thing to do. >> >> 1 filemark can not be used for EOT, it is EOF, you can't tell if what you >> read next is another file or not that may have been left by a previosly >> longer usage on the tape. >> >>> >>> So- let me know, either via this list or privately. >>> Thanks in advance... >> >> Won't work, or would you care to explain how we are now suppose to detect >> logical EOT? > > The driver detects EOT during reads. Subsequent reads from the user > application return no data. A user application that detects a residual > twice in a row knows it is at EOT. Nearly all other Unix systems work fine > with this mechanism. Convince me. Every night, I do a partial backup, one file on tape for each file system, about 12 in all. Subsequently I read the tape and list contents until I hit EOT. OK, the first time I use a tape, there will be nothing behind it. But the next time, the total length of tape written may be shorter, so there will be data after logical EOT. How is the program going to know where to stop? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver
On Monday, 15 November 1999 at 11:01:05 -0800, Matthew Jacob wrote: > > > On Mon, 15 Nov 1999, Rodney W. Grimes wrote: > >>> >>> Reread/reresponse, sorry- ENOCOFFEE: >>> >>> > > 1 filemark can not be used for EOT, it is EOF, you can't tell if what you > read next is another file or not that may have been left by a previosly > longer usage on the tape. > >>> >>> >>> Well, read until *BLANK CHECK* seems to be what the driver can and should >>> do. Let me ponder this some- I believe what I propose actually works fine >>> for all the devices we currently support (hell, I use it all the time >>> myself). If you can provide an actual example of a SCSI tape device that >>> if you take FreeBSD-current or FreeBSD-3.3 and do a 'mt seteotmodel 1' on >>> and *not* be able to detect EOT, let me know! >> >> You won't get ``blank check'' if the tape has previosly been written >> past where you just finished writing. Instead you often get trash. > > Sorry, no. When you write a tape with these devices there's always a > leading erased area. That's why if you overwrite the front a tape you > can't skip past this area to recover data you really need. A misfeature of > modern technology. Is this anchored in the standards? What about DLT? What about future drives? I certainly wouldn't rely on anything that isn't guaranteed to stay that way. What happens if I write a tape on FreeBSD and read it in on System V? >> In your other message you talk about the driver getting 2 residuals >> in a row, well, unless you write the 2 EOF's you won't always get that... >> depends on if the tape drive does it automagically (which many newer >> drives do, they write 2 eof's and backspace over 1 of them for you when >> ever you tell them to write EOF, the drive itself uses 2 EOF's to >> determine logical EOT :-)). > > I repeat what I said in other mail- can you actually show me a tape drive > where what I propose really doesn't work? I think this question is the wrong way round. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 2.95.2
On Tue, 16 Nov 1999 06:46:12 PST, Manfred Antar wrote: > Did it build for you ? Yes. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 2.95.2
At 01:06 PM 11/16/99 +0200, Sheldon Hearn wrote: >On Mon, 15 Nov 1999 13:22:23 PST, Manfred Antar wrote: > > > I did the same and everything works. > > But XFree86 from the ports collection will not build. > >By the way, I just tested the build using gcc-2.95.2 both with and >without the threads support. So you really are going to need to provide >more information. > >Ciao, >Sheldon. Did it build for you ? I get Full build of XFree86 done or something like that at the end of the build but it only took 20 minutes. It usually takes about 1 hour. I have to go to work but I'll start another build and see if I can get some of the errors listed Thanks Manfred = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
< said: > Perhaps the above should be written as: > sum += ntohs(*(u_char *)w << 8); > to avoid the undefined union access (answer.us). No. The IP checksum is defined in a manner which is endian-independent. Adding calls to ntohs() would only confuse matters further. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Sheldon Hearn writes: > > > > > >On Tue, 16 Nov 1999 07:19:52 +0100, Poul-Henning Kamp wrote: > > > >> >Why don't we get rid of the 'e' option to ps while we are at it > >> >considering how much of a security hole it is. > >> > >> Hmm, well, I like to have it around for root at least... > > > >Exactly. > > > >In a perfect world, the -e option will only allow inspection of the > >environment of processes for which the owner of the ps process has > >sufficient priveledge. > > Yes that makes sense, because if all comes to all they could attach > a debugger and find it that way anyway. If the command line is obtained other ways, then the easiest way to implement this should be to delay opening the mem file until it's required and turn off the setgid bit for the open. Or better yet, turn off setgid entirely and use sysctl and eproc for everything, but allow -e to work if the user could open /proc/*/mem.. Or something like that. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 2.95.2
On Mon, 15 Nov 1999 13:22:23 PST, Manfred Antar wrote: > I did the same and everything works. > But XFree86 from the ports collection will not build. By the way, I just tested the build using gcc-2.95.2 both with and without the threads support. So you really are going to need to provide more information. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current Make World
> Speaking of which, is their an archive (web based?) of the FreeBSD-current > mailing list (how about others?)? I didn't see one linked in my searches > around the web pages. I am currently working on a full-text search/archive of Open Source mailing lists, which should be up at http://www.osdigger.com for testing before the end of the year. The site will have searchable archives of over 300 lists including *BSD, Linux, Perl, Apache, KDE, Gnome, and lots lots more :) Watch this space. -Matt Matt Hamilton[EMAIL PROTECTED] Hamilton Computing +44 (0)797 707 2482 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pcm0 is not found: "unknown0:"
I was running a kernel from end of august, and everything worked fine (IBM PC 300 PL, PII-350, 128 MB RAM, built-in audio): Oct 5 13:28:29 aylee /kernel: pcm1 (CS423x/Yamaha/AD1816 sn 0x) at 0x530-0x537 irq 5 drq 1 flags 0x13 on isa Since make world last week: unknown0: at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 unknown1: on isa0 unknown2: at port 0x120-0x127 on isa0 I looked in the archives, and could see some people had a related problems -- but it's not a missing chip ID in this case... Here's DMESG output: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Mon Nov 15 14:03:48 CET 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/AYLEE Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 348486590 Hz CPU: Pentium II/Xeon/Celeron (348.49-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ff real memory = 134213632 (131068K bytes) config> pnp 1 0 os enable port0 0x534 port2 0x220 irq0 5 drq0 1 drq1 3 Invalid command or syntax. Type `?' for help. config> flags wdc0 0xa0ffa0ff No such device: wdc0 Invalid command or syntax. Type `?' for help. config> flags wdc1 0xa0ffa0ff No such device: wdc1 Invalid command or syntax. Type `?' for help. config> q avail memory = 127262720 (124280K bytes) Preloaded elf kernel "kernel" at 0xc02bf000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc02bf09c. VESA: v2.0, 4096k memory, flags:0x1, mode table:0xc0275442 (122) VESA: Matrox Graphics Inc. Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 oltr: oltr_pci_probe pcib1: at device 1.0 on pci0 pci1: on pcib1 oltr: oltr_pci_probe vga-pci0: irq 0 at device 1.0 on pci1 isab0: at device 2.0 on pci0 isa0: on isab0 ata-pci0: at device 2.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 oltr: oltr_pci_probe chip1: at device 2.2 on pci0 oltr: oltr_pci_probe chip2: at device 2.3 on pci0 fxp0: irq 11 at device 3.0 on pci0 fxp0: Ethernet address 00:04:ac:d9:40:0e xl0: <3Com 3c905B-TX Fast Etherlink XL> irq 9 at device 16.0 on pci0 xl0: Ethernet address: 00:10:5a:c0:08:11 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto oltr: oltr_pci_probe vga-pci1: at device 18.0 on pci0 fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: on ppbus 0 lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 oltr0: oltr_probe oltr0: auto assigning card. oltr0: [00:00:83:79:d5:c4] oltr0 at port 0xa20 irq 10 drq 7 on isa0 oltr0: Adapter modes - TRLLD_MODE_16M TRLLD_MODE_PHYSICAL unknown0: at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 unknown1: on isa0 unknown2: at port 0x120-0x127 on isa0 IP packet filtering initialized, divert enabled, rule-based forwarding disabled, logging disabled oltr0 XXX: driver didn't set ifq_maxlen ad0: ATA-4 disk at ata0 as master ad0: 4028MB (8249472 sectors), 8184 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 0 depth queue, UDMA33 Creating DISK ad0 Creating DISK wd0 ad1: ATA-4 disk at ata1 as master ad1: 4028MB (8249472 sectors), 8184 cyls, 16 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 0 depth queue, UDMA33 Creating DISK ad1 Creating DISK wd1 acd0: CDROM drive at ata1 as slave acd0: read 5500KB/s (5500KB/s), 128KB buffer, DMA acd0: supported read types: CD-R, CD-RW, CD-DA, packet acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-RW 120mm audio disc loaded, unlocked, lock protected Mounting root from ufs:/dev/ad0s1a oltr0: adapter status good. (close completed/self-test) fxp0: promiscuous mode enabled -- It is hoped the US DoJ will not coerce Microsoft Corporation into releasing its source code to the competition: - the national security of several large states would be at risk - paramedics aren't ready to deal with hysterical giggling on a planetary scale To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
On Mon, Nov 15, 1999 at 02:18:24PM -0800, Matthew Dillon wrote: > Why don't we get rid of the 'e' option to ps while we are at it > considering how much of a security hole it is. I've never liked the > 'e' option. If we get rid of the 'e' option we should also get rid of showing the command line args - both might leak private data. Anyone writing programs which don't want to leak data should know not to put it on the command line or in the environment. If the 'e' option is removed from FreeBSD it doesn't make the life of anyone writing programs any easier 'cos other versions of Unix will continue to expose the environment variables. Also, setting environment variables is a simple way of exporting data from a program. For example you can set variables in hosts.allow saying where the connection the created the process came from and then examine this with ps -e later. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Tue, 16 Nov 1999, Pierre Beyssac wrote:
> On Tue, Nov 16, 1999 at 03:17:43PM +1100, Bruce Evans wrote:
> > On Mon, 15 Nov 1999, Pierre Beyssac wrote:
> > > - volatile u_short answer = 0;
> > > + union {
> > > + u_int16_t us;
> > > + u_int8_t uc[2];
> > > + } answer;
> >
> > This has indentation bugs.
>
> Uh, which one(s) do you mean exactly? The 4-space indented union
> (I just followed style(9)) or the double space before uc[2] (it
> was just to align us and uc vertically)?
See Sheldon's reply. u_int16_t and u_int8_t are too wide for the
normal indentation rules to apply. Various inconsistent formattings
are used for them. E.g., in Lite2, uses an extra space
in one struct and an extra tab in the others. This is another reason
to use u_short :-).
> > ping.c still assumes that u_short is u_int16_t everywhere else.
>
> But in_cksum() is more or less self-contained. Probably it's more
> consistent (even withing in_cksum which uses u_short elsewhere) to
> change back the union to u_short and u_char, though.
There are better examples to copy in the kernel. They still use too
many shorts, ints and union hacks, however. The alpha version is
most interesting.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc 2.95.2
On Mon, 15 Nov 1999 13:22:23 PST, Manfred Antar wrote: > I did the same and everything works. > But XFree86 from the ports collection will not build. That's not a very useful description of the problem. :-) Did you answer "YES" or "NO" to the following question? Do you want to compile with threads support? (experimental) The default is "YES" if you just press enter, and the commit message for the addition of threads support was ominous: | revision 1.47 | date: 1999/11/13 01:28:19; author: jmz; state: Exp; lines: +11 -0 | Add support for threads (use at your own risk) | | Submitted by: Carlos A M dos Santos <[EMAIL PROTECTED]> If this isn't your problem and you actually wanted help, you'll need to describe more accurately what goes wrong such that XFree86 "will not build". Here read "cut'n'paste build errors". :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
In message <[EMAIL PROTECTED]>, Sheldon Hearn writes: > > >On Tue, 16 Nov 1999 07:19:52 +0100, Poul-Henning Kamp wrote: > >> >Why don't we get rid of the 'e' option to ps while we are at it >> >considering how much of a security hole it is. >> >> Hmm, well, I like to have it around for root at least... > >Exactly. > >In a perfect world, the -e option will only allow inspection of the >environment of processes for which the owner of the ps process has >sufficient priveledge. Yes that makes sense, because if all comes to all they could attach a debugger and find it that way anyway. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps -e
On Mon, 15 Nov 1999 16:27:12 PST, Matthew Dillon wrote: > I shudder to think that people might actually start depending on this > non-feature. Your shuddering comes too late. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
On Tue, 16 Nov 1999 07:19:52 +0100, Poul-Henning Kamp wrote: > >Why don't we get rid of the 'e' option to ps while we are at it > >considering how much of a security hole it is. > > Hmm, well, I like to have it around for root at least... Exactly. In a perfect world, the -e option will only allow inspection of the environment of processes for which the owner of the ps process has sufficient priveledge. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Tue, Nov 16, 1999 at 10:58:06AM +0200, Sheldon Hearn wrote: > The word ``union'' doesn't appear in style(9) and a 1 tab indent is used > consistently in the examples of structs. Use 1 tab. Right, I reread style(9) and I apparently misunderstood the following part which only applies to code (mainly inside a statement): > Indentation is an 8 character tab. Second level indents are four spaces. -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
> >And, also, we need to get rid of the 'e' option to ps entirely. It's a > >major security hole. > >I agree that we need to get rid of 'e' and any other options that allow > reading another process's environment. How about protecting the -e option by a test for setuid() == 0 instead of removing it entirely. That would remove the security concern, but still retain the function for root. Removing the function for root is useless from a security point of view, as anybody with root access can simply compile an alternative version of ps(1) with -e back in it. Cheers. -- ++ . | John Saunders - mailto:[EMAIL PROTECTED] (EMail) | ,--_|\|- http://www.nlc.net.au/ (WWW) | / Oz \ |- 02-9489-4932 or 04-1822-3814 (Phone) | \_,--\_/ | NORTHLINK COMMUNICATIONS P/L - Supplying a professional, | v| and above all friendly, internet connection service. | ++ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Tue, 16 Nov 1999 09:45:36 +0100, Pierre Beyssac wrote:
> > - volatile u_short answer = 0;
> > + union {
> > + u_int16_t us;
> > + u_int8_t uc[2];
> > + } answer;
> Uh, which one(s) do you mean exactly? The 4-space indented union
> (I just followed style(9))
The word ``union'' doesn't appear in style(9) and a 1 tab indent is used
consistently in the examples of structs. Use 1 tab.
> or the double space before uc[2] (it was just to align us and uc
> vertically)?
Use tabs for that as well.
Look at the rest of ping.c, and you'll see that 4-space indents aren't
used except to prevent line-wrap in one weird case of a switch block and
for run-over lines.
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Tue, Nov 16, 1999 at 03:17:43PM +1100, Bruce Evans wrote:
> On Mon, 15 Nov 1999, Pierre Beyssac wrote:
> > - volatile u_short answer = 0;
> > + union {
> > + u_int16_t us;
> > + u_int8_t uc[2];
> > + } answer;
>
> This has indentation bugs.
Uh, which one(s) do you mean exactly? The 4-space indented union
(I just followed style(9)) or the double space before uc[2] (it
was just to align us and uc vertically)?
> ping.c still assumes that u_short is u_int16_t everywhere else.
But in_cksum() is more or less self-contained. Probably it's more
consistent (even withing in_cksum which uses u_short elsewhere) to
change back the union to u_short and u_char, though.
> This `answer' variable has nothing to do with the final `answer' variable.
> The latter should not be a union. The original code apparently reuses
> `answer' to do manual register allocation for ancient compilers.
Agreed.
> Perhaps the above should be written as:
>
> sum += ntohs(*(u_char *)w << 8);
>
> to avoid the undefined union access (answer.us).
Uh... I'm not sure I don't prefer the union, actually :-)
--
Pierre Beyssac [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
