Re: DVD-ram
crypt0genic [EMAIL PROTECTED] writes: I have a Lacie DVD-RAM drive, it work great under windows, here is the DMESG i g et from it, I hope this is of some help. LaCie don't make drives, they just package them in ugly boxes with noisy fans. One of my cow-orkers (with whom I share an office) had an external LaCie disk hooked up to his Mac until I threatened to pour Coca Cola into the PSU (this was after I'd hinted several times that the handles on his G3 would serve very well for chucking it out the window) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DVD-ram
crypt0genic [EMAIL PROTECTED] writes: * Dag-Erling Smorgrav ([EMAIL PROTECTED]) [990701 11:47]: LaCie don't make drives, they just package them in ugly boxes with noisy fans. Im not sure what model you are refering too, but the drive I have is in a stylish external box with a fan that doesnt make a whisper on noise, It also doesnt make any sound when reading/writeing. The unit is so sturdy I rekon I could through it at a brick wall without damaging it! Overall Im very pleased with this piece of hardware and when it is supported under freebsd it will be one of my most prised devices. : ) The box may look solid, but the drive inside is a standard OEM component (Matshita, IIRC) which would certainly not survive the impact, no matter how sturdy an enclosure it's in - unless the enclosure has internal shock mounts, which would frankly surprise the hell out of me given LaCie's generally low prices. You get what you pay for. And the fan may be nice and silent now, but how do you know that'll last? My cow-orker's unit was two months old when the fan started screaming like a butchered pig. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to start to be a hacker?
Not to let this become a passage of right or anything. ITYM "rite of passage". HTH, HAND! DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Repalcement for grep(1)
Jamie Howard [EMAIL PROTECTED] writes:
I made the version in FreeBSD 4.0 my target except for -A num, -B num, -C,
-num, and -Z. These are not required by the Single Unix Specification or
POSIX and I felt they would bloat my code too significantly.
I find those quite useful, and I don't see how they'd bloat your code
a lot. You need a line @queue and a $toprint counter, as well as $lead
and $trail counters. $regexp is the expression to search for, and
$line is a scratch variable. Initialize by setting $lead to the -A
argument, $trail to the -B argument; if you encounter -C, set $lead
and $trail to 2; if you encounter -num, set $lead and $trail to
num. Now for the search algorithm in Perl:
$toprint = 0;
@queue = qw();
while ($line = INPUT) {
if ($toprint) {
print $line;
--$toprint;
} else {
shift @queue if (@queue $lead);
push @queue, $line;
}
next unless ($line ~ m/$regexp/o);
while (@queue) {
print shift @queue;
}
$toprint = $trail;
}
This should be trivial to translate to C. The only non-trivial part of
implementing this stuff is that you have to trick getopt() to make
-num work. You'll have to put a : at the start of your getopt()
string and examine every argument getopt() complains about.
Hope this helps... keep up the good work!
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Repalcement for grep(1)
Jamie Howard [EMAIL PROTECTED] writes: All of the code is original except for binary.c. It is used with the -a option to prevent searching binary files. binary.c is extricated from less-332's binary checking code. I was just that lazy. Less's binary checking code is a tad too strict. It complains about files with my name at the top (e.g. /usr/include/fetch.h in FreeBSD 3.x and 4.x) in non-ISO8859 locales. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
[accidentally b0rked the cc: line; apologies to those who get this twice] Jason Thorpe [EMAIL PROTECTED] writes: On 07 Jul 1999 20:57:16 +0200 Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: Don't use err() indiscriminately after a malloc() failure; malloc() doesn't set errno. This is a bug in malloc(3), is it not? According to the Single Unix Specification, yes. URL:http://www.opengroup.org/onlinepubs/007908799/xsh/malloc.html DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Repalcement for grep(1)
Jamie Howard [EMAIL PROTECTED] writes: On Sun, 4 Jul 1999, Archie Cobbs wrote: There are two special cases- of bracket expressions: the bracket expressions `[[::]]' and `[[::]]' match the null string at the beginning and end of a word respectively. Perhaps this will help with -w? Yes, I received a patch from Simon Burge which implements this. It also beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does. No, because there are scripts out there (e.g. ports/Mk/bsd.port.mk) which rely on this behaviour. I suggest you explore the magic of the nmatch and pmatch arguments to regexec() :) Specifically, the pattern matched a word if: ((pmatch[0].rm_so == 0 || !isalpha(line[pmatch[0].rm_so-1])) (pmatch[0].rm_eo == len || !isalpha(line[pmatch[0].rm_eo]))) This is off the top of my head, from reading the man page: you'll have to try it out to see if it works. You might want to replace isalpha with something less restrictive, such as isalnum(), or: #define isword(x) (isalnum(x) || (x) == '_') (judging from empirical observation, the latter corresponds to what GNU grep does) As for full-line matches (-x), simply check that (pmatch[0].rm_so == 0 pmatch[0].rm_eo == len) This should save you from playing games with back-references. (both code snippets assume that line points to a line of text from the input and that len is the length of that line minus the newline) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Repalcement for grep(1)
BTW, the end-of-line handling is wrong; grep will fail to select a line where the pattern appears at the end and the line is not terminated by a newline. I'm working on a fix (and on implementing my solution for -w and -x). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Assar Westerlund [EMAIL PROTECTED] writes:
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
+ realpat = grep_malloc(strlen(pattern) + sizeof("^(")
+ + sizeof(")$") + 1);
Why not just use asprintf?
Doesn't matter, thsis code is gone in the latest version. You though
the linux 'kernel of the day' was bad; now you have the FreeBSD 'grep
of the minute' :)
In this case it doesn't matter but in general this function is wrong.
malloc(0) can return NULL.
Agreed.
And besides, I really don't think this is a grep function but actually
is useful for programs that don't have any strategy for handling out
of memory errors and might as well die (with a descriptive error
message, of course). Let's call it emalloc and let's put in somewhere
where it can be used.
Too simple to warrant that, and other programs will likely want to
handle the error differently.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Jon Ribbens [EMAIL PROTECTED] writes: "Daniel C. Sobral" [EMAIL PROTECTED] wrote: OTOH, though, FreeBSD's malloc() is very unlikely to return an out of memory error. Why is that? Because FreeBSD overcommits memory. You can allocate (almost) as much memory as you want regardless of how much RAM / swap you have. You won't run into trouble unless you actually try to use too much of it. What happens if the process hits its resource limits? Malloc() fails with ENOMEM. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Devloper
Assem Salama [EMAIL PROTECTED] writes: I am interested in helping in the development in FreeBSD. I'm not a hotshot programmer but I know how to program. Could someone please send me the available projects that I can work on and some info about them? URL:http://www.freebsd.org/handbook/contrib.html DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
Greg Lehey [EMAIL PROTECTED] writes: mdoc.samples(7). Now tell me that that's not intuitive. It would seem mdoc.samples(7) does not teach by example :) des@des ~% man -t mdoc.samples | lpr -Plex Usage: .Rv -std sections 2 and 3 only DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Determining the return address
Alfred Perlstein [EMAIL PROTECTED] writes: erm, can't you point multiple signal handler entries to the same routine? can't you also make it so that signals aren't defered or blocked while another handler is executing so you may actually re-enter the handler before it's complete. I use good ol' signal() rather than sigaction(), so no, signals can't interrupt one another's handlers. specifically how you say you increment it, then decrement it, if you have multiple handlers where one can interupt another you can have the counter get jumbled. Not if increment / decrement is atomic. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Overcommit and calloc()
"Kelly Yancey" [EMAIL PROTECTED] writes:
I'm afraid my question got lost amongst the see of overcommit messages. :)
I was curious if calloc() was overcommitted also?
Here's our calloc() implementation:
void *
calloc(num, size)
size_t num;
register size_t size;
{
register void *p;
size *= num;
if ( (p = malloc(size)) )
bzero(p, size);
return(p);
}
so the answer is yes, it overcommits, but the bzero() may cause the
system to run out of swap.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
Oscar Bonilla [EMAIL PROTECTED] writes: the idea is to have an entry in the /etc/passwd enabling LDAP lookups. the Entry would be of the form ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com Horrible idea. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
Oscar Bonilla [EMAIL PROTECTED] writes: On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote: Oscar Bonilla [EMAIL PROTECTED] writes: the idea is to have an entry in the /etc/passwd enabling LDAP lookups. the Entry would be of the form ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com Horrible idea. suggestions? /etc/auth.conf DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Overcommit and calloc()
"Kelly Yancey" [EMAIL PROTECTED] writes: Ahh...but wouldn't the bzero() touch all of the memory just allocated functionally making it non-overcommit? No. If it were an "non-overcomitting malloc", it would return NULL and set errno to ENOMEM, instead of dumping core. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Overcommit and calloc()
"Kelly Yancey" [EMAIL PROTECTED] writes: I don't know how many programs make use of calloc() but would not a more efficient algorithm be to better integrate it with malloc() such that if there is a fragment on the heap which can be used, bzero() it and return that, otherwise, simply call sbrk() and return that (since it is already zero'ed). Currently, in the event that malloc() simply returns newly sbrk()'ed memory, we unnecessarily zero it again. I don't see the point. I've seen very few examples of justified calloc() use. For instance, I see a lot of people use calloc() instead of malloc() when allocating strings, just to make sure they'll be terminated after a strncpy(), instead of simply setting the last character to '\0' after the strncpy(). When I allocate memory, I usually intend to put something in it. There's always the odd struct sockaddr_in which I bzero() before filling it in, but they're usually on the stack. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Overcommit and calloc()
John-Mark Gurney [EMAIL PROTECTED] writes: Dag-Erling Smorgrav scribbled this message on Jul 20: When I allocate memory, I usually intend to put something in it. There's always the odd struct sockaddr_in which I bzero() before filling it in, but they're usually on the stack. and even then, I don't believe in filling sockaddr_in w/ bzero, I believe in using getsockaddr on it so that you actually get all the fields filled out properly... See? One less reason to use bzero() / calloc() :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
BSDI binary compatibility
What kinds of BSDI binaries are we supposed to be able to run? I haven't had any luck getting *any* BSDI binaries to run on my (very recent) 4.0-CURRENT box. I have a handful of BSDI binaries, some of which are identified as: des@des ~/yes/bsdi/shopsite% file wwwinstall.cgi wwwinstall.cgi: unknown pure executable des@des ~/yes/bsdi/shopsite% ./wwwinstall.cgi zsh: bus error (core dumped) ./wwwinstall.cgi others (ls and cat from BSDI 4.0): des@des ~/yes/bsdi/cmc% file ./ls ./ls: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked, stripped des@des ~/yes/bsdi/cmc% ./ls ELF binary type not known. Use "brandelf" to brand it. zsh: abort ./ls and finally a few static ones Chris Costello was kind enough to build for me: des@des ~/yes/bsdi/cmc/bsdi_static% file hello hello: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, not stripped des@des ~/yes/bsdi/cmc/bsdi_static% ./hello ELF binary type not known. Use "brandelf" to brand it. zsh: abort ./hello DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: amandad zombies (fwd)
Snob Art Genre [EMAIL PROTECTED] writes: I've been beating my head against a mysterious problem for some time now, and I'm hoping that you folks can help me out. When I run amanda, seven out of my 16 hosts don't respond. Of these, some are Solaris and some are FreeBSD 3.1-RELEASE, but it's the FreeBSD ones I'm concerned with at the moment. I'm using Amanda 2.4.1. (Note that the symptomology on the Solaris machines is different, which is why I'm posting this to -hackers.) This was fixed in revision 1.49 of src/usr.sbin/inetd.c (1999/05/11). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
UDMA problems on ALI chipsets
Is anybody working on getting UltraDMA to work on ALI chipsets? I have a scratch box with that chipset and an UDMA disks and can test patches and perform minor debugging if anyone needs me to. ide_pci0: Acer Aladdin IV/V (M5229) Bus-master IDE controller irq 0 at device 15.0 on pci0 DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IDE breakage
6 drq 2 ___disk fd0 at fdc0 drive 0 ___controller wdc0at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff ___disk wd0 at wdc0 drive 0 ___disk wd1 at wdc0 drive 1 ___controller wdc1at isa? port "IO_WD2" bio irq 15 flags 0xa0ffa0ff ___disk wd2 at wdc1 drive 0 ___disk wd3 at wdc1 drive 1 ___options ATAPI ___options ATAPI_STATIC ___device acd0 ___pseudo-devicevn 2 ___ ___# Networking ___options INET ___options IPFIREWALL ___options IPFIREWALL_VERBOSE ___options DUMMYNET ___options NMBCLUSTERS=8192 ___device fxp0 ___device xl0 ___pseudo-deviceether ___pseudo-deviceloop 2 ___pseudo-devicebpfilter 4 ___pseudo-devicepty 64 ___ ___# Console ___controller atkbdc0 at isa? port IO_KBD tty ___device atkbd0 at isa? tty irq 1 ___device vga0at isa? port ? conflicts ___device sc0 at isa? tty ___options "MSGBUF_SIZE=40960" ___ ___ root@xxx /# strings -n 3 /kernel.old | grep '^___' ___# ___# Kernel configuration for X servers. ___# ___ ___machine "i386" ___cpu "I586_CPU" ___cpu "I686_CPU" ___identX ___maxusers 256 ___ ___# General options ___options "COMPAT_43" ___options KTRACE ___options SYSVSHM ___options SYSVMSG ___options SYSVSEM ___options INCLUDE_CONFIG_FILE ___options USERCONFIG ___options VISUAL_USERCONFIG ___ ___config kernel root on wd0 ___ ___# Buses ___controller isa0 ___controller pnp0 ___controller pci0 ___ ___device npx0at isa? port IO_NPX irq 13 ___ ___# File system ___options FFS ___options FFS_ROOT ___options MFS ___options MFS_ROOT ___options PROCFS ___options SOFTUPDATES ___ ___controller fdc0at isa? port "IO_FD1" bio irq 6 drq 2 ___disk fd0 at fdc0 drive 0 ___controller wdc0at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff ___disk wd0 at wdc0 drive 0 ___disk wd1 at wdc0 drive 1 ___controller wdc1at isa? port "IO_WD2" bio irq 15 flags 0xa0ffa0ff ___disk wd2 at wdc1 drive 0 ___disk wd3 at wdc1 drive 1 ___options ATAPI ___options ATAPI_STATIC ___device acd0 ___pseudo-devicevn 2 ___ ___# Networking ___options INET ___options IPFIREWALL ___options IPFIREWALL_VERBOSE ___options DUMMYNET ___options NMBCLUSTERS=8192 ___device fxp0 ___device xl0 ___pseudo-deviceether ___pseudo-deviceloop 2 ___pseudo-devicebpfilter 4 ___pseudo-devicepty 64 ___ ___# Console ___controller atkbdc0 at isa? port IO_KBD tty ___device atkbd0 at isa? tty irq 1 ___device vga0at isa? port ? conflicts ___device sc0 at isa? tty ___options "MSGBUF_SIZE=40960" ___ ___ DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE breakage
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: I'm experiencing serious problems with DMA (even normal DMA, not UDMA) on recent versions of -STABLE. Here's an excerpt from messages; kernel #3 is a recent -STABLE (yesterday's sources), while kernel #2 is 3.2-RELEASE. The config file for both is identical. A brand new kernel (from the same sources and config, but built in a clean build directory) produces the following: Jul 22 11:29:17 irc /kernel: Copyright (c) 1992-1999 FreeBSD Inc. Jul 22 11:29:17 irc /kernel: Copyright (c) 1982, 1986, 1989, 1991, 1993 Jul 22 11:29:17 irc /kernel: The Regents of the University of California. All rights reserved. Jul 22 11:29:17 irc /kernel: FreeBSD 3.2-STABLE #0: Thu Jul 22 10:54:31 CEST 1999 Jul 22 11:29:17 irc /kernel: [EMAIL PROTECTED]:/usr/src/sys/compile/X Jul 22 11:29:17 irc /kernel: Timecounter "i8254" frequency 1193182 Hz Jul 22 11:29:17 irc /kernel: Timecounter "TSC" frequency 348204679 Hz Jul 22 11:29:17 irc /kernel: CPU: Pentium II/Xeon/Celeron (348.20-MHz 686-class CPU) Jul 22 11:29:17 irc /kernel: Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Jul 22 11:29:17 irc /kernel: Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR Jul 22 11:29:17 irc /kernel: real memory = 134217728 (131072K bytes) Jul 22 11:29:17 irc /kernel: avail memory = 127774720 (124780K bytes) Jul 22 11:29:17 irc /kernel: Preloaded elf kernel "kernel" at 0xc023c000. Jul 22 11:29:17 irc /kernel: Probing for devices on PCI bus 0: Jul 22 11:29:17 irc /kernel: chip0: Intel 82443BX host to PCI bridge rev 0x02 on pci0.0.0 Jul 22 11:29:17 irc /kernel: chip1: Intel 82443BX host to AGP bridge rev 0x02 on pci0.1.0 Jul 22 11:29:17 irc /kernel: xl0: 3Com 3c905-TX Fast Etherlink XL rev 0x00 int a irq 11 on pci0.13.0 Jul 22 11:29:17 irc /kernel: xl0: Ethernet address: 00:60:08:e8:6b:1d Jul 22 11:29:17 irc /kernel: xl0: autoneg complete, link status good (full-duplex, 100Mbps) Jul 22 11:29:17 irc /kernel: chip2: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.20.0 Jul 22 11:29:17 irc /kernel: ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.20.1 Jul 22 11:29:17 irc /kernel: chip3: Intel 82371AB Power management controller rev 0x02 on pci0.20.3 Jul 22 11:29:17 irc /kernel: Probing for devices on PCI bus 1: Jul 22 11:29:17 irc /kernel: vga0: ATI model 4742 graphics accelerator rev 0x5c int a irq 11 on pci1.0.0 Jul 22 11:29:17 irc /kernel: Probing for PnP devices: Jul 22 11:29:17 irc /kernel: Probing for devices on the ISA bus: Jul 22 11:29:17 irc /kernel: sc0 on isa Jul 22 11:29:17 irc /kernel: sc0: VGA color 16 virtual consoles, flags=0x0 Jul 22 11:29:17 irc /kernel: atkbdc0 at 0x60-0x6f on motherboard Jul 22 11:29:17 irc /kernel: atkbd0 irq 1 on isa Jul 22 11:29:17 irc /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Jul 22 11:29:17 irc /kernel: fdc0: FIFO enabled, 8 bytes threshold Jul 22 11:29:17 irc /kernel: fd0: 1.44MB 3.5in Jul 22 11:29:17 irc /kernel: wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa Jul 22 11:29:17 irc /kernel: wdc0: unit 0 (wd0): Maxtor 90640D4, DMA, 32-bit, multi-block-16 Jul 22 11:29:17 irc /kernel: wd0: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S Jul 22 11:29:17 irc /kernel: wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa Jul 22 11:29:17 irc /kernel: wdc1: unit 0 (atapi): CD-ROM CDU611-Q/2.0c, removable, accel, dma, iordis Jul 22 11:29:17 irc /kernel: acd0: drive speed 1723KB/sec, 256KB cache Jul 22 11:29:17 irc /kernel: acd0: supported read types: CD-R, CD-RW, CD-DA Jul 22 11:29:17 irc /kernel: acd0: Audio: play, 16 volume levels Jul 22 11:29:17 irc /kernel: acd0: Mechanism: ejectable tray Jul 22 11:29:17 irc /kernel: acd0: Medium: no/blank disc inside, unlocked Jul 22 11:29:17 irc /kernel: npx0 on motherboard Jul 22 11:29:17 irc /kernel: npx0: INT 16 interface Jul 22 11:29:17 irc /kernel: vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa Jul 22 11:29:17 irc /kernel: IP packet filtering initialized, divert disabled, rule-based forwarding disabled, unlimited logging Jul 22 11:29:17 irc /kernel: DUMMYNET initialized (990504) Jul 22 11:29:17 irc /kernel: changing root device to wd0s1a Jul 22 11:29:17 irc /kernel: wd0: DMA failure, DMA status 5active Jul 22 11:29:17 irc last message repeated 17 times Jul 22 11:29:17 irc /kernel: wd0: DMA failure, DMA status 7error,active Jul 22 11:29:17 irc /kernel: Jul 22 11:29:17 irc /kernel: Jul 22 11:29:17 irc /kernel: Fatal trap 12: page fault while in kernel mode Jul 22 11:29:17 irc /kernel: fault virtual address = 0x44 Jul 22 11:29:17 irc /kernel: fault code= supervisor read, page not present Jul 22 11:29:17 irc /kernel: instruction pointer = 0x8:0xc01813ca Jul 22 11:29:17 irc /kernel: stack pointer = 0x10:0xc9599b84 Jul 22 11:29:17 irc /kernel: frame pointer = 0x10:0xc9599bf4 Jul 22 11:29:17 irc /kernel: code segment = base 0x0, limit 0x
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
Sheldon Hearn [EMAIL PROTECTED] writes:
I know exactly why you see what you see when you do what you do. All I
can say is "don't do that", because I can't think of a why to cater for
what you're doing in a sensible fashion.
I think you're jumping to conclusions. What I'd like to see is a
tcpdump log of the UDP scan ('tcpdump -i ed0 udp or icmp'). Yes, I
know it's going to be huge.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
Andre Albsmeier [EMAIL PROTECTED] writes: Comes in private email. It's about 130KB after which tcpdump crashed with: zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp Weird. Very weird. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
Andre Albsmeier [EMAIL PROTECTED] writes: Just to overcome speculations :-) I just tested it on another machine with the same result. If have tested it now between all 3 machines in each direction. Same result. Weird. I'm unable to reproduce it; my test box responds to UDP queries but does not log them (though it logs TCP queries). I'll update to the latest inetd and try again. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
TCP/IP hardening
Attached are patches which implement four new sysctl variables: * net.inet.icmp.dropredirect: if set to 1, ignore ICMP REDIRECT packets. * net.inet.icmp.logredirect: if set to 1, log all ICMP REDIRECT packets (before optionally dropping them). * net.inet.tcp.restrict_rst: if set to 1, do not emit TCP RST packets. Conditional on the TCP_RESTRICT_RST kernel option, which defaults to off. * net.inet.tcp.drop_synfin: if set to 1, drop TCP packets with both the SYN and FIN options set. Conditional on the TCP_DROP_SYNFIN kernel option, which defaults to off. The logredirect code uses inet_ntoa, which is a bad idea. I'm open to suggestions for a better solution. Also, these sysctl variables should be described in a man page somewhere, but I'm not sure which one. These patches compile, but are not fully tested. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] Index: etc/defaults/rc.conf === RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.23 diff -u -r1.23 rc.conf --- rc.conf 1999/07/26 10:49:33 1.23 +++ rc.conf 1999/07/26 19:11:51 @@ -48,6 +48,11 @@ tcp_extensions="NO"# Set to Yes to turn on RFC1323 extensions. log_in_vain="NO" # Disallow bad connection logging (or YES). tcp_keepalive="YES"# Kill dead TCP connections (or NO). +tcp_restrict_rst="NO" # Set to YES to restrict emission of RST +tcp_drop_synfin="NO" # Set to YES to drop TCP packets with SYN+FIN + # NOTE: this breaks rfc1644 extensions (T/TCP) +icmp_dropredirect="NO" # Set to YES to ignore ICMP REDIRECT packets +icmp_logredirect="NO" # Set to YES to log ICMP REDIRECT packets network_interfaces="auto" # List of network interfaces (or "auto"). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0x" # Sample alias entry. Index: etc/rc.network === RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.52 diff -u -r1.52 rc.network --- rc.network 1999/07/26 15:17:23 1.52 +++ rc.network 1999/07/26 19:11:51 @@ -197,6 +197,16 @@ echo -n ' broadcast ping responses=YES' sysctl -w net.inet.icmp.bmcastecho=1 /dev/null fi + +if [ "X$icmp_dropredirect" = X"YES" ]; then + echo -n ' ignore ICMP redirect=YES' + sysctl -w net.inet.icmp.dropredirect=1 /dev/null +fi + +if [ "X$icmp_logredirect" = X"YES" ]; then + echo -n ' log ICMP redirect=YES' + sysctl -w net.inet.icmp.logredirect=1 /dev/null +fi if [ "X$gateway_enable" = X"YES" ]; then echo -n ' IP gateway=YES' @@ -216,6 +226,16 @@ if [ "X$tcp_keepalive" = X"YES" ]; then echo -n ' TCP keepalive=YES' sysctl -w net.inet.tcp.always_keepalive=1 /dev/null +fi + +if [ "X$tcp_restrict_rst" = X"YES" ]; then + echo -n ' restrict TCP reset=YES' + sysctl -w net.inet.tcp.restrict_rst=1 /dev/null +fi + +if [ "X$tcp_drop_synfin" = X"YES" ]; then + echo -n ' drop SYN+FIN packets=YES' + sysctl -w net.inet.tcp.drop_synfin=1 /dev/null fi if [ "X$ipxgateway_enable" = X"YES" ]; then Index: sys/conf/options === RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.144 diff -u -r1.144 options --- options 1999/07/05 20:19:34 1.144 +++ options 1999/07/26 19:11:51 @@ -222,6 +222,8 @@ PPP_FILTER opt_ppp.h TCP_COMPAT_42 opt_compat.h TCPDEBUG +TCP_RESTRICT_RST opt_tcp_input.h +TCP_DROP_SYNFINopt_tcp_input.h IPFILTER opt_ipfilter.h IPFILTER_LOG opt_ipfilter.h SLIP_IFF_OPTS opt_slip.h Index: sys/i386/conf/LINT === RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.620 diff -u -r1.620 LINT --- LINT1999/07/26 05:47:17 1.620 +++ LINT1999/07/26 19:11:51 @@ -465,9 +465,23 @@ optionsIPDIVERT#divert sockets optionsIPFILTER#kernel ipfilter support optionsIPFILTER_LOG#ipfilter logging -#options IPFILTER_LKM#kernel support for ip_fil.o LKM optionsIPSTEALTH #support for stealth forwarding +#options IPFILTER_LKM#kernel support for ip_fil.o LKM optionsTCPDEBUG + +# The following options add sysctl variables for contr
Re: Proposal for new syscall to close files
Peter Jeremy [EMAIL PROTECTED] writes: If it ever gets committed (I don't think it's particularly useful myself), That's 2 against, 1 (me) for. Three against. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
replacing grep(1)
Jamie Howard ([EMAIL PROTECTED]), with a little help from yours truly, has written a BSD-licensed version of grep(1) which has all the functionality of our current (GPLed) implementation, plus a little more, in one seventh the source code and one fourth the binary code. What's more, the code is actually possible for mere mortals to read and understand. The source code is available for download from freefall: URL:http://www.freebsd.org/~des/software/grep-0.7.tar.gz I move that we replace GNU grep in our source tree with this implementation, once it's been reviewed by all concerned parties. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
Sheldon Hearn [EMAIL PROTECTED] writes: Version 0.3 broke port-building badly. Does version 0.7 make it through a build of a whole stack of ports? Yes. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
Sheldon Hearn [EMAIL PROTECTED] writes: In this case, the implementation we'll be introducing will introduce a performance loss, not a gain. Can you document that? As far as stability goes, there's a loss involved _if_ passing the GNU grep regression tests is important. Do you mean that Jamie's implementation doesn't pass those regression tests? If they don't, we can fix it before importing it into the tree. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Free BSDI CD!
"Brian F. Feldman" [EMAIL PROTECTED] writes: My point was that it's not a very important thing to do to give out FreeBSD CDs like BSD/OS gives out trial versions of their wares. Yes, it is. Try doing an FTP install across a 28k8 or 33k6 modem some time. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linear buffers in VESA screen modes
Andrew Gordon [EMAIL PROTECTED] writes: The application for which I need this is to support capture from the bktr driver onto the screen (ie. so that you can watch TV without X). With the above hack and a small (100-line) program it works very nicely - far tidier than installing X just for this purpose on some embedded systems where I need this capability. Might one persuade you to release that 100-line program? :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
James Howard [EMAIL PROTECTED] writes: DES tells me he has a new version (0.10) which mmap()s. It supposedly cuts the run time down significantly, I do not have the numbers in front of me. Unfortunetly he has not posted this version yet so I cannot download it and run it myself. It's in the usual place (ftp://ftp.ofug.org/pub/grep/). He also says that if mmap fails, he drops back to stdio. This should only happen in the NFS case, the 2G case, etc. Any case in which a) the file is too large to mmap, b) the file is not a regular file, or c) mmap() fails (e.g. NFS). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
John-Mark Gurney [EMAIL PROTECTED] writes: it was VERY simple to do... and attached is the patch... this uses the option REG_STARTEND to do what the copy was trying to do... all of the code to use REG_STARTEND was already there, it just needed to be enabled.. Funnily, I experience a near-doubling of running time with similar patches. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: No MAXUID ?
Sheldon Hearn [EMAIL PROTECTED] writes: Another question I should have asked in my original mail is this: are there magical reasons why we should want pwd_mkdb to bleat for every encountered UID greater that 65535 ? How many times do I have to go through this? There is no "artificial limitation in pwd_mkdb". pwd_mkdb warns against UIDs larger than 65535 because legacy software that uses unsigned short instead of uid_t will break with large UIDs. There were even a few such cases in our tree that I fixed less than a year ago IIRC. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: No MAXUID ?
Sheldon Hearn [EMAIL PROTECTED] writes: Would you be happy with changing things so that only one warning is generated? Something like "9 max_uid 65535: others may exist"? The current behaviour is quite annoying with large passwd files. :-) Sure, and maybe modify the warning to say something like "legacy software may not support UIDs larger than 65535" DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
grep-0.11
ftp://ftp.ofug.org/pub/grep/grep-0.11.tar.gz More (gprof-assisted) speedups. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
"Daniel C. Sobral" [EMAIL PROTECTED] writes: Dag-Erling Smorgrav wrote: To be precise, I experience a 30% decrease in system time and a 100% increase in user time when I use RE_STARTEND and eliminate the malloc() / memcpy() calls in procfile(). Could you please test my patch that removes malloc() but bot memcpy()? Here it is again, though against an old version: Yeah. You can do even better by declaring ln static and never free()ing it. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
"Daniel C. Sobral" [EMAIL PROTECTED] writes: Could you please test my patch that removes malloc() but bot memcpy()? Here it is again, though against an old version: Bingo. REG_STARTEND is significantly more expensive than memcpy(). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: readdirplus is very cool, any other nfs client suggestions?
Alfred Perlstein [EMAIL PROTECTED] writes: DES: can you elaborate? you think it may cause problems with amd since it's like an NFS buffer isn't it and would work over the loopback... I used loopback mounts to test NFS make worlds a while ago (there were places where make world would bomb because chflags doesn't work on NFS) and experienced deadlock problems. Somebody (I don't remember who exactly) told me that this was a known problem with the NFSv3 code; reading over loopback mounts works fine, but writing apparently results in deadlocks. Search the archives; the commit logs should give you an idea of when this was (check the logs for Makefiles that use chflags). root@des ~# current -l -F Makefile chflags src/Makefile.inc1 src/lib/libc/sys/Makefile.inc src/lib/libc_r/Makefile src/release/Makefile src/sys/alpha/conf/Makefile.alpha src/sys/i386/conf/Makefile.i386 src/sys/pc98/conf/Makefile.pc98 src/usr.bin/Makefile src/usr.bin/chflags/Makefile src/usr.bin/chpass/Makefile src/usr.bin/passwd/Makefile DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
John-Mark Gurney [EMAIL PROTECTED] writes: Sheldon Hearn scribbled this message on Aug 1: Would you need these entries if inetd let you specify port numbers instead of service names? I vote for allowing inetd.conf to specify a port number instead of a service name... it should be very easy to make the modification, and I'm willing to do all the work, assuming no one on -committers objects.. The correct way to do this is to fix getservbyname() so it accepts port numbers. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
Sheldon Hearn [EMAIL PROTECTED] writes: On 02 Aug 1999 13:05:17 +0200, Dag-Erling Smorgrav wrote: The correct way to do this is to fix getservbyname() so it accepts port numbers. Would this not still require modifications to /etc/services for services not already mentioned in that file? Allow me to re-quote the message I answered: I vote for allowing inetd.conf to specify a port number instead of a service name... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: readdirplus is very cool, any other nfs client suggestions?
Matthew Dillon [EMAIL PROTECTED] writes: The buildworld chflags problems were fixed around a month ago I think. No, I fixed them in february or march. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: readdirplus is very cool, any other nfs client suggestions?
Tim Vanderhoek [EMAIL PROTECTED] writes: Set INSTALLFLAGS_EDIT=:S/schg/,/ to remove these when doing a make world, if needed. Please try to understand what the issue is before butting in. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: readdirplus is very cool, any other nfs client suggestions?
Matthew Dillon [EMAIL PROTECTED] writes: Ok, then there is a real good chance localhost mounts will work now. I'm happy to hear that, since NFSv3 is significantly faster than NFSv2 on loopback mounts :) I'm running a buildworld test right now with /usr/src and /usr/obj both on NFSv3 localhost mounts. Yeah, I was doing installworlds with /usr, /usr/src and /usr/obj NFS-mounted (in a chroot tree on the server, because I got tired of doing it over PLIP). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD voice synthesis
Ville-Pertti Keinonen [EMAIL PROTECTED] writes: I certainly don't expect any of the available voices to be able to pronounce Finnish names correctly, even with phonetic specifications. If the software were *designed* to speak Finnish, I'd expect it to cope with Finnish much better than it currently does with English, seeing as you guys have nearly phonetic spelling. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Results of investigating optimizing calloc()...
"Kelly Yancey" [EMAIL PROTECTED] writes: [...] Which reminds me - has anyone thought of using DMA for zeroing pages, to avoid cache invalidation? The idea is to keep a chunk of zeroes on disk and DMA it into memory instead of clearing pages "manually". This assumes your disk supports DMA, of course. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fetch: default to passive mode?
"Chuck Youse" [EMAIL PROTECTED] writes: I have a really strong urge to submit a PR to make fetch default to passive mode, instead of requiring a command-line switch ... fetch(1) honors FTP_PASSIVE_MODE. des@des /usr/freebsd/current% lcvs log -r1.31 src/etc/login.conf RCS file: /home/ncvs/src/etc/login.conf,v Working file: src/etc/login.conf head: 1.32 branch: locks: strict access list: symbolic names: RELENG_3_2_PAO: 1.26.2.3.0.2 RELENG_3_2_PAO_BP: 1.26.2.3 RELENG_3_2_0_RELEASE: 1.26.2.3 RELENG_3_1_0_RELEASE: 1.26.2.1 RELENG_3: 1.26.0.2 RELENG_3_BP: 1.26 RELENG_2_2_8_RELEASE: 1.9.2.7 RELENG_3_0_0_RELEASE: 1.22 RELENG_2_2_7_RELEASE: 1.9.2.7 RELENG_2_2_6_RELEASE: 1.9.2.7 RELENG_2_2_5_RELEASE: 1.9.2.3 RELENG_2_2_2_RELEASE: 1.9 RELENG_2_2: 1.9.0.2 keyword substitution: kv total revisions: 43;selected revisions: 1 description: revision 1.31 date: 1999/05/28 11:07:16; author: jkh; state: Exp; lines: +2 -2 Set FTP_PASSIVE_MODE=YES by default in the default login class. = DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fetch: default to passive mode?
"Daniel O'Connor" [EMAIL PROTECTED] writes: Speaking of fetch features.. Are there any plans to make fetch use a http proxy for ftp requests like ftp does? Yes. I intend to implement this in libfetch when I get around to rewriting the HTTP code. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Disk label recovery - request for suggestions.
Josef Karthauser [EMAIL PROTECTED] writes: If so, what extra work is required to make it work with non UFS file systems - is 'disklabel' used on non UFS fs's? Disklabel doesn't work at the fs level, it works at the slice level - dividing slices into partitions, in which you can create file systems. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Disk label recovery - request for suggestions.
Josef Karthauser [EMAIL PROTECTED] writes: Ahha - of course. Ok, let me re-phrase the question then. By looking at the contents of the superblocks on a UFS file system it's possible to reconstruct a disklabel for a slice. Well, it's possible to reconstruct the label information for *that particular UFS file system*, since if you know the location of the superblock (or one of its backup copies), you can determine the offset and size of the FS. It won't tell you anything about *other* partitions though. Is this trick possible with other kinds of file systems too? That's totally dependent on the particular file system. For instance, a swap partition contains no metadata (that I know of), so all you can do is deduce it's size and position from the sizes and positions of surrounding partitions, and of the slice they're in. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Disk label recovery - request for suggestions.
Josef Karthauser [EMAIL PROTECTED] writes: On Wed, Aug 11, 1999 at 06:23:24PM +0200, Dag-Erling Smorgrav wrote: Josef Karthauser [EMAIL PROTECTED] writes: Ahha - of course. Ok, let me re-phrase the question then. By looking at the contents of the superblocks on a UFS file system it's possible to reconstruct a disklabel for a slice. Well, it's possible to reconstruct the label information for *that particular UFS file system*, since if you know the location of the superblock (or one of its backup copies), you can determine the offset and size of the FS. It won't tell you anything about *other* partitions though. That's ok, because each slice has its _own_ label. If the bios partition table loses it's mind that's a little more work :). You're confusing partitions and slices. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
Tony Finch [EMAIL PROTECTED] writes: Kenny Drobnack [EMAIL PROTECTED] wrote: This may be a stupid question, but what's to keep from putting xfs in FreeBSD? Is there something in the licenses that says you can't use GPL'ed software and software under the BSD License together? Yes. The BSD licence requirement for acknowledging UCB in any advertising conflicts with the GPL requirement that further restrictions should not be added to those already in the GPL. This prevents you from relicensing BSD software under the GPL. It does not prevent you from selling an OS that has both BSD and GPL bits, as long as the GPL bits come with full source. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New tests for test(1)
Graham Wheeler [EMAIL PROTECTED] writes: I was writing a script yesterday, and I wanted to have a test to compare the modification time of two files. test(1) doesn't have the ability to do this. In the end I worked around this by using make(1), but it set me thinking - wouldn't it be a good idea to add some new tests to test(1), to compare files based on criteria like size or modification date? NetBSD's test(1) utility has this (-nt and -ot). We should probably merge in their changes. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
Jason Thorpe [EMAIL PROTECTED] writes: On 12 Aug 1999 11:01:06 +0200 Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: This prevents you from relicensing BSD software under the GPL. It does not prevent you from selling an OS that has both BSD and GPL bits, as long as the GPL bits come with full source. If you have an executable object which includes GPL'd code, you must supply FULL SOURCE for the *entire* object, not just the GPL'd bits. We're talking separate binaries here. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Review please] (was: Re: cvs commit: src/gnu/usr.bin/man/manpath manpath.config)
Ruslan Ermilov [EMAIL PROTECTED] writes: How about the following patch. It adds an OPTIONAL_MANPATH directive, which is equivalent to the MANDATORY_MANPATH, except an absence of the directory is not considered an error. Sure. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
KATO Takenori [EMAIL PROTECTED] writes: The kernel runs with four different levels of security. ! Any super-user process can raise the security level, but no process can lower it. How about "The security level can only be raised by the super-user, and cannot be lowered by anyone." instead? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFD: bogomips CPU performance metric
Wilko Bulte [EMAIL PROTECTED] writes: "The Wrath of Satoshi" (free interpretation of "The Wrath of Khan") 8-) The question is, does "The Wrath of Satoshi" also have Kirstie Alley in the role of Lt. Saavik? And if it doesn't, what else does it have that makes it worth watching? Too bad she's a scientologist. DES (http://www.moviebbs.com/gallery/samples/s-025-ka.jpg) -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
Matthew Dillon [EMAIL PROTECTED] writes: So making DDB 'secure-level friendly' would be a useful thing tgo do, I think. The idea is not to disable DDB, but to simply limit the actions that can be performed within it if the securelevel has been raised. The sysadmin would only be allowed to issue passive commands, cont, and 'panic'. The sysadmin would not be allowed to modify the running system. That's an excellent idea - it shouldn't be too hard to add a kernel option (say, DDB_RESTRICTED) and #ifndef the "dangerous" commands. DES (must... write... patches...) -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More press
Dirk GOUDERS [EMAIL PROTECTED] writes: Oh, sorry -- my "browse-url-at-mouse" function made http://www.zdnet.com/zdtv/screensavers/answerstips/story/02c36562c23246242c00.html of it... Netscape uses commans to separate parameters to the OpenURL command. Fortunately, the API is open and documented, so there's nothing to stop someone from writing a small command-line util that does the equivalent of "netscape -remote" except faster and better. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent motd including os info
[moving to -hackers]
"Rodney W. Grimes" [EMAIL PROTECTED] writes:
So when can we see this commited
Already done (-CURRENT only). I've had requests (notably from Yan
Koum) to backport it to -STABLE, but I won't do it so close to a
release.
the only thing I would like
changed is actually a general format of output change in /etc/rc.network,
if you have a few of the ``tcp_*'' knobs set the line length gets
a bit long, could be change the ``echo -n'''s to ``echo \t'' and loose
the trailing ``echo '.'''.
I don't consider that much of a problem, except in cases where
individual scripts / options produce output which breaks the line
(this is mostly a problem with ports). I wouldn't mind the changes you
suggest, but I don't care enough to actually go ahead and do it.
One thing I'd like very much, though, would be to have the output of
fsck -p logged somehow - but since we don't have anything mounted rw
when fsck runs, it's a bit hard to log to disk. You could of course
do something like this:
fsck_output="$(/sbin/fsck -p)"
/sbin/mount -at nonfs
echo "${fsck_output}" /var/run/fsck.boot
but then you wouldn't be able to see the output while it runs. The
only solution I can think of is the following:
fsck_output="$(/sbin/fsck -p | /bin/tee /dev/console)"
/sbin/mount -at nonfs
echo "${fsck_output}" /var/run/fsck.boot
but I don't expect people to be happy about moving tee(1) from
/usr/bin to /bin.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent motd including os info
"Rodney W. Grimes" [EMAIL PROTECTED] writes: One thing I'd like very much, though, would be to have the output of fsck -p logged somehow [...] Actually I would like _all_ the output from /etc/rc* to be avaliable after boot. It should be in the syscons scroll back buffer, [...] No. The scrollback may be too short (especially after an fsck of a large filesystem after a crash), and it may even be empty (if you put something like VESA_132x60 in allscreens_flags in rc.conf) And solving only 1 piece of output from /etc/rc is an incomplete concept. I really like to know if ntpdate stepped my clock 23 seconds for some reason, thats why this (usually means a clock chip has gone zonkers :-)): Doesn't ntpdate log what it does with syslog? If not, I think whichever syscall it is that ntpdate uses to adjust the time should printf() or log() the change. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent motd including os info
"Rodney W. Grimes" [EMAIL PROTECTED] writes: No. The scrollback may be too short (especially after an fsck of a large filesystem after a crash), and it may even be empty (if you put something like VESA_132x60 in allscreens_flags in rc.conf) We can tune the size of the scroll back buffer can't we? Yes, but we don't want to increase the default size too much. And fsck output even after a crash is usually not that long, if it gets long it usually has more problems than fsck -p can deal with and stops any way. You've obviously never fsck'ed a largish soft-updated filesystem after a power outage. Why does switching display mode screw up the scroll back buffer? That sounds broken to me. Because you have to resize the scrollback to accomodate the new line width. You're welcome to fix it. I've tried, and decided that it was far from a SMOP and that it would have to wait until I have more than a few hours' continuous free time. Doesn't ntpdate log what it does with syslog? If you give it the -s option, yes it will syslog it. But doing that to everything in /etc/rc* seems like a pain in the *ss... Lazy people never achieve much. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More press
Dominic Mitchell [EMAIL PROTECTED] writes: If you follow the link from "netscape -help", you end up at: http://home.netscape.com/newsref/std/remote.c The page you attempted to access was not found on Netscape's web site. You may have typed its location incorrectly, or it may have been moved, deleted, or incorporated into another part of Netscape's site. To report a broken link, please send a message to feedback. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: style question
Gregory Bond [EMAIL PROTECTED] writes: Us humans can see that j is not used without being set, but cc can't. How do I remove this warning in a style(9)-compatible way? Initialize j. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: style question
Neil Blakey-Milner [EMAIL PROTECTED] writes:
On Fri 1999-09-17 (18:21), Gregory Bond wrote:
I'm looking at cleaning up a few compile nits and I'm wondering what the
officially approved way of silencing "may not be used" warnings:
int
foo(int flag)
{
int j;
j = 0;
if (flag)
j = 1;
return j;
}
Hmf, I just realized:
int
foo(int flag)
{
return !!flag;
}
or
#define foo(x) (!!(x))
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FTP directory listing with ftpio(3) and fetch(3)
Jaakko Salomaa [EMAIL PROTECTED] writes: Hey, how am I supposed to fetch directory listing with ftpio(3) or fecth(3)? ftpio doesn't seem to contain necessary functions for it, and fetch's ones aren't implemented. Type 'man 3 fetch', scroll down to the BUGS section, and see the light. Next, scroll back up to the AUTHORS section and find out who to contact :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qcam/cqcam driver
Christoph Kukulies [EMAIL PROTECTED] writes: Just a question: has the Quickcam and ColorQuickcam (if there was any) been removed from the kernel? And, if yes, for what reason? Yeah, they were nuked ages ago. OTOH, I always wanted one of those babies, and ISTR that Connectix has a free developer program where you can sign up to get tech specs and stuff. If somebody donates the eq I might hack up a KLD module :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Voice modems
Does anyone have any experience with controlling voice modems from FreeBSD, doing stuff like DTMF-driven phone reservation etc? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Stupid Newbie questions (was re: developer assessment)
[EMAIL PROTECTED] writes: http://www.blackhelicopters.org/~dispatch/stupid-bsd-questions.txt Looks great! BTW, do the hot twins down the hall have a phone number? 8) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Determine # of open files via fdesc
Zhihui Zhang [EMAIL PROTECTED] writes: I do not know whether it is a good idea to determine the number of open files of a process by enabling fdesc in the kernel. Anyway, I do the following: # mount_fdesc -o union fdesc /dev # ls -al /dev/fd list cat list total 1 crw--- 1 root tty 12, 0 Oct 15 17:09 0 -rw-r--r-- 1 root wheel 0 Oct 15 17:09 1 crw--- 1 root tty 12, 0 Oct 15 17:09 2 drw-r--r-- 5 root wheel 1024 Oct 15 17:09 3 dr--r--r-- 2 root wheel 512 Oct 15 16:28 4 I do not know why 3 and 4 are labeled as directory. 1 was labeled as character device but is changed probably by the redirection . I run a small program to open three files and run forever in the background. After this, I expect to see three more items under /dev/fd, but there are not. Can anyone explain this to me? Each process only sees its own file descriptors. The five descriptors you see above belong to ls. 0 (stdin) and 2 (stderr) are whichever tty or pty you typed this into, 1 (stdout) is the file you redirected the output from ls into, 3 is /dev and 4 is /dev/fd. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Determine # of open files via fdesc
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Each process only sees its own file descriptors. The five descriptors you see above belong to ls. 0 (stdin) and 2 (stderr) are whichever tty or pty you typed this into, 1 (stdout) is the file you redirected the output from ls into, 3 is /dev and 4 is /dev/fd. OBTW, this is adequately documented in the fdesc(5) man page. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD and HP Jornado
Wes Peters [EMAIL PROTECTED] writes: Jornada/BSD would be killer. Sounds like someone misspelled "Jordana/BSD" (Jordan wearing a miniskirt... scary) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Finer-grained securelevel: proof of concept
Patches are available from http://www.freebsd.org/~des/. This is strictly proof-of-concept; the patches demonstrate that fine-grained security knobs can be implemented with minimal code impact. No documentation is provided, RTFS. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Finer-grained securelevel: proof of concept
Robert Watson [EMAIL PROTECTED] writes: Very clean, pretty, etc -- only one object: please call it something other than capabilities :-). [deletia] Please read the thread on -security and -arch that lead to these patches. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Finer-grained securelevel: proof of concept
Robert Watson [EMAIL PROTECTED] writes: On 21 Oct 1999, Dag-Erling Smorgrav wrote: Robert Watson [EMAIL PROTECTED] writes: Very clean, pretty, etc -- only one object: please call it something other than capabilities :-). [deletia] Please read the thread on -security and -arch that lead to these patches. I did--hence my comments. You seem to have missed the part that says "this should be integrated with process-level and user-level capabilities". DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep (again) and regex speed ups
James Howard [EMAIL PROTECTED] writes: I submitted a PR (bin/14342) which adds a lot of speed to mismatches in Henry Spencer's regex code. Who knows a lot about regex whom I can bug? Umm, how about Henry Spencer [EMAIL PROTECTED]? :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Running unattended (ifo FFS thread)
Kevin Day [EMAIL PROTECTED] writes: The problem is that 'fsck -py' ignores the 'p' and will fsck every time, even if it's unneeded. This takes ages for me. I believe I submitted a PR with a 'fix' to fsck. 'fsck -p || fsck -y' should do the trick. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP -stable
Julian Elischer [EMAIL PROTECTED] writes: You should do a 'config' again before making a kernel from -stable sources. *Always* re-run config(8) before building a kernel from updated sources. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new IPFW
[moving from -ipfw and -arch to -hackers]
Tony Landells [EMAIL PROTECTED] writes:
One concern I would have with that is that there are a lot of tools
built on BPF that I would prefer to not be able to run on the firewall.
Don't confuse BPF with promiscuous mode. BPF is simply a programmable
packet filter and does not in and of itself represent a security risk.
Promiscuous mode allows a host to capture packets not destined to
itself, and may represent a security risk on shared media networks
(e.g. 10Base2, unswitched 10BaseT).
The attached patch prevents switching into promiscuous mode when
running in "Network secure mode" (securelevel 3 or higher).
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
Index: if.c
===
RCS file: /home/ncvs/src/sys/net/if.c,v
retrieving revision 1.77
diff -u -r1.77 if.c
--- if.c1999/11/22 02:44:51 1.77
+++ if.c1999/11/29 12:52:07
@@ -908,6 +908,8 @@
int error;
if (pswitch) {
+ if (securelevel = 3)
+ return (EPERM);
/*
* If the device is not configured up, we cannot put it in
* promiscuous mode.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: new IPFW
Luigi Rizzo [EMAIL PROTECTED] writes: The attached patch prevents switching into promiscuous mode when running in "Network secure mode" (securelevel 3 or higher). What happens with yout patch if i need to run an mrouted on such a machine ? It'll crash and burn, which demonstrates the inadequacy of the secure level mechanism. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
New option to ping(8): dump packet contents
The attached patch adds a -D option to ping(8) which makes it dump the
payload of the reply packet instead of comparing it to the payload of
the original request packet. This is useful in cases where the target
host purposeldy modifies the payload before replying, e.g. if you hack
your stack to report the load average in echo reply packets.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
Index: ping.c
===
RCS file: /home/ncvs/src/sbin/ping/ping.c,v
retrieving revision 1.49
diff -u -r1.49 ping.c
--- ping.c 2000/01/14 23:40:38 1.49
+++ ping.c 2000/01/19 13:48:53
@@ -133,6 +133,7 @@
#define F_POLICY 0x4000
#endif /*IPSEC_POLICY_IPSEC*/
#endif /*IPSEC*/
+#define F_DUMP 0x8000
/*
* MAX_DUP_CHK is the number of bits in received table, i.e. the maximum
@@ -234,10 +235,10 @@
datap = outpack[8 + PHDR_LEN];
#ifndef IPSEC
- while ((ch = getopt(argc, argv, "I:LQRT:c:adfi:l:np:qrs:t:v")) != -1)
+ while ((ch = getopt(argc, argv, "I:LQRT:c:adDfi:l:np:qrs:t:v")) != -1)
#else
#ifdef IPSEC_POLICY_IPSEC
- while ((ch = getopt(argc, argv, "I:LQRT:c:adfi:l:np:qrs:t:vP:")) != -1)
+ while ((ch = getopt(argc, argv, "I:LQRT:c:adDfi:l:np:qrs:t:vP:")) != -1)
#endif /*IPSEC_POLICY_IPSEC*/
#endif
{
@@ -256,6 +257,9 @@
case 'd':
options |= F_SO_DEBUG;
break;
+ case 'D':
+ options |= F_DUMP;
+ break;
case 'f':
if (uid) {
errno = EPERM;
@@ -837,7 +841,13 @@
cp = (u_char*)icp-icmp_data[PHDR_LEN];
dp = outpack[8 + PHDR_LEN];
for (i = PHDR_LEN; i datalen; ++i, ++cp, ++dp) {
- if (*cp != *dp) {
+ if (options F_DUMP) {
+ if ((i - PHDR_LEN) % 16 == 8)
+ putchar(' ');
+ if ((i - PHDR_LEN) % 16 == 0)
+ putchar('\n');
+ printf(" %02x", *dp);
+ } else if (*cp != *dp) {
(void)printf("\nwrong data byte #%d should be 0x%x but was 0x%x",
i, *dp, *cp);
printf("\ncp:");
IBM Netfinity 5600
The following patch adds support for the host to pci bridge on IBM's
new Netfinity 5600. It's based on the 3.4-RELEASE code, I don't know
if it'll apply to 4.0 or 5.0. It's also quite a hack; I guess what
you'd really want to do is either use NBUS instead of 2, or extract
some kind of "correct" value from the chipset. Also, I have no idea
what the chipset's real name is.
Without the patch, the second (64-bit) PCI bus will not work, which is
kind of a bummer since the first (32-bit) PCI bus only has two slots.
For the curious, this was hacked up and tested on Netfinity 5600
assembly no. 52, which we have on loan from IBM to replace two downed
servers (the disk enclosure died on us - never buy Trimm again!). It's
a lovely little thang, I'd absolutely *love* to have a truckload of
them in my server room...
Kudos to Zippy for pointing us in the right direction.
Index: pcisupport.c
===
RCS file: /home/ncvs/src/sys/pci/pcisupport.c,v
retrieving revision 1.86.2.13
diff -u -r1.86.2.13 pcisupport.c
--- pcisupport.c1999/11/01 22:48:34 1.86.2.13
+++ pcisupport.c2000/03/22 05:30:07
@@ -233,8 +233,14 @@
}
#endif
}
-
+/* Hackety-hack-hack */
+static void
+fixbushigh_nf5600(pcici_t tag)
+{
+ tag-secondarybus = tag-subordinatebus = 2;
+}
+
static const char*
chipset_probe (pcici_t tag, pcidi_t type)
{
@@ -242,6 +248,10 @@
char*descr;
switch (type) {
+ /* IBM Netfinity 5600 */
+ case 0x00091166:
+ fixbushigh_nf5600(tag);
+ return ("IBM Netfinity 5600 host to PCI bridge");
/* Intel -- vendor 0x8086 */
case 0x00088086:
/* Silently ignore this one! What is it, anyway ??? */
DES (half past six aye emm, still at work...)
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Linprocfs observation.
David Malone [EMAIL PROTECTED] writes: I haven't checked carefully, but I expect that the linprocfs code has the same problem as the FreeBSD procfs code, in that it can expose suid executables which would not usually be run 'cos they are in inaccessible directories. That is indeed correct, and a severe oversight on my part. 2) Make the "exe" file in /linproc/pid/ a symlink to "./private/exe", which is the file which gives you the executables real vnode. Sounds good. I'll get to it. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ILOVEYOU
Alexander Langer [EMAIL PROTECTED] writes: Thus spake Matthew Dillon ([EMAIL PROTECTED]): The 'virus' is the warning message itself, silly! Nope, ILOVEYOU is a real virus. ...but it does not wipe your hard disk, no matter what the warning message said. It does wipe all jpeg and mp3 files though... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
newsyslog(8) hack
I've hacked newsyslog(8) to accept a list of log files to process on
the command line (very useful in combination with -F). See attached
patches. I'll commit this in a few days if noone objects.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
Index: newsyslog.8
===
RCS file: /home/ncvs/src/usr.sbin/newsyslog/newsyslog.8,v
retrieving revision 1.24
diff -u -r1.24 newsyslog.8
--- newsyslog.8 2000/04/04 08:50:01 1.24
+++ newsyslog.8 2000/05/08 18:57:20
@@ -28,6 +28,7 @@
.Op Fl Fnrv
.Op Fl f Ar config_file
.Op Fl a Ar directory
+.Op Ar file ...
.Sh DESCRIPTION
.Nm Newsyslog
is a program that should be scheduled to run periodically by
@@ -355,6 +356,11 @@
option is useful for diagnosing system problems by providing you with
fresh logs that contain only the problems.
.El
+.Pp
+If additional command line arguments are given,
+.Nm
+will only examine log files that match those arguments; otherwise, it
+will examine all files listed in the configuration file.
.Sh FILES
.Bl -tag -width /etc/newsyslog.conf -compact
.It Pa /etc/newsyslog.conf
Index: newsyslog.c
===
RCS file: /home/ncvs/src/usr.sbin/newsyslog/newsyslog.c,v
retrieving revision 1.27
diff -u -r1.27 newsyslog.c
--- newsyslog.c 2000/04/04 08:50:01 1.27
+++ newsyslog.c 2000/05/08 18:52:47
@@ -95,7 +95,7 @@
char hostname[MAXHOSTNAMELEN + 1]; /* hostname */
char *daytime; /* timenow in human readable form */
-static struct conf_entry *parse_file();
+static struct conf_entry *parse_file(char **files);
static char *sob(char *p);
static char *son(char *p);
static char *missing_field(char *p, char *errline);
@@ -121,7 +121,7 @@
PRS(argc, argv);
if (needroot getuid() geteuid())
errx(1, "must have root privs");
- p = q = parse_file();
+ p = q = parse_file(argv + optind);
while (p) {
do_entry(p);
@@ -214,7 +214,6 @@
if ((p = strchr(hostname, '.'))) {
*p = '\0';
}
- optind = 1; /* Start options parsing */
while ((c = getopt(argc, argv, "nrvFf:a:t:")) != -1)
switch (c) {
case 'n':
@@ -253,11 +252,12 @@
* process
*/
static struct conf_entry *
-parse_file(void)
+parse_file(char **files)
{
FILE *f;
char line[BUFSIZ], *parse, *q;
char *errline, *group;
+ char **p;
struct conf_entry *first = NULL;
struct conf_entry *working = NULL;
struct passwd *pass;
@@ -274,6 +274,21 @@
if ((line[0] == '\n') || (line[0] == '#'))
continue;
errline = strdup(line);
+
+ q = parse = missing_field(sob(line), errline);
+ parse = son(line);
+ if (!*parse)
+ errx(1, "malformed line (missing fields):\n%s", errline);
+ *parse = '\0';
+
+ if (*files) {
+ for (p = files; *p; ++p)
+ if (strcmp(*p, q) == 0)
+ break;
+ if (!*p)
+ continue;
+ }
+
if (!first) {
working = (struct conf_entry *) malloc(sizeof(struct
conf_entry));
first = working;
@@ -281,12 +296,6 @@
working-next = (struct conf_entry *) malloc(sizeof(struct
conf_entry));
working = working-next;
}
-
- q = parse = missing_field(sob(line), errline);
- parse = son(line);
- if (!*parse)
- errx(1, "malformed line (missing fields):\n%s", errline);
- *parse = '\0';
working-log = strdup(q);
q = parse = missing_field(sob(++parse), errline);
Re: Netfinity 5600 patches
[EMAIL PROTECTED] writes: As far as I can see, these patches aren't needed for 4.0-STABLE. I have a 4.0-STABLE system here with no kernel patches, and it seems to be working fine. Note that there is already support for the RCC chipsets in /sys/i386/isa/pcibus.c. See attached boot messages. You're right - I never got around to testing a recent 4.0 on the 5600. I've tried running 3.4-RELEASE as well as whichever version of 4.0 is on the latest snapshot CD. For 3.x, isn't Andrew Gallatin's patch more general? See http://docs.FreeBSD.org/cgi/getmsg.cgi?fetch=60828+0+archive/2000/freebsd-smp/2423.freebsd-smp Looks like it - and Andrew's the one who added support for the RCC in the first place. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible bug in /usr/bin/makewhatis
Jos Backus [EMAIL PROTECTED] writes: This patch gets rid of the Broken pipe messages. No need to name the loop... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel programming
Alexander Langer [EMAIL PROTECTED] writes: Thus spake Dag-Erling Smorgrav ([EMAIL PROTECTED]): Alexander Langer [EMAIL PROTECTED] writes: There recently (last week or something) was a thread here or on another mailinglist on how to debug kernel moduls, which is a little bit tricky. It's also documented in the handbook. Well, actually debugging modules is a little bit more tricky than debugging kernels with statically linked drivers. It's still documented in the handbook. I don't see where you find a contradiction here. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: specify a different kernel to boot
Zhiui Zhang [EMAIL PROTECTED] writes: Is there a way to specify a kernel other than /kernel to boot from? I do not want to do this manually, I want to put it into some configuration file. Thanks, 'man loader' DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel Hacking (i tried not to make it lame)
Alfred Perlstein [EMAIL PROTECTED] writes: * [EMAIL PROTECTED] [EMAIL PROTECTED] [010125 19:04] wrote: 2.) you should know some basic stuff about FreeBSD internels (i am planning on getting The Design and Implementation of the 4.4BSD Operating System Well more than 'basic' hopefully. :) Good choice on a book, others to look at are: "UNIX Internals 'the new frontiers'" Vahalia "The Basic Kernel Source Secrets" Jolitz I haven't read Vahalia, so I can't comment on that one, but both McKusick et al. and Jolitz are seriously outdated - you can basically forget anything they tell you about memory management (particularly virtual memory), interrupt handling, spls, and probably scheduling as well; and none of them tell you much about writing device drivers (which is what kernel newbies most often want to do). On the other hand, the Daemon book (McKusick et al.) still has some fairly relevant sections (some of part 2, about half of part 3 and most of part 4), and does a good job of demystifying the kernel on a psychological level, i.e. teaching you that most of it really isn't deep voodoo and you can understand it if you try. In my experience, this psychological block is a much bigger obstacle to overcome than actual technical complexity. (hmm, I must remember to drop by Mustang Jack next time I'm in NYC) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: newbie - Audio CD question
vijay [EMAIL PROTECTED] writes: Hi, I am new to FreeBSD. I wanted to know if I can play audio CDs on "my" system. 'man cdcontrol' DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bash2 removes SSH_CLIENT from the environment
Chet Ramey [EMAIL PROTECTED] writes: Bash uses the presence of SSH_CLIENT to decide whether or not to run the shell startup files for a non-interactive shell (like it attempts to do for rsh). [...] Feh. Here's a nickel, kid, get yourself a real shell. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syscall kernel modules on 3.0-release
Matthew Luckie [EMAIL PROTECTED] writes: I have written a KLD module that implements a syscall I wrote this module on 3.2-release, although this module is going to be used on a 3.0-release machine Don't run 3.0. Is it possible for me to hack my kernel module to work on freebsd 3.0-release? Don't run 3.0. So my question is, is it possible for me to hack my kernel module to work on FreeBSD 3.0-release? Don't run 3.0. Even when released, 3.0 was not meant for production use, or in fact any use at all except by developers and those interested in helping out debugging RELENG_3 so we would one day be able to call it -STABLE. It's quite conceivably the most buggy and incomplete FreeBSD release ever. So allow me to repeat my advice: Don't run 3.0. In fact, don't run any kind of 3.x at all, since we stopped fixing bugs (except for some, but not all, known security holes) about half a year ago. If you absolutely must run RELENG_3, don't run anything but the very latest 3.5-STABLE (cvsup and cvs are your friends). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syscall kernel modules on 3.0-release
Matthew Luckie [EMAIL PROTECTED] writes: I completely understand your plea to not use 3.0 release. I am personally using 4.2-stable. Its not my decision to use 3.0 I beleive the computers running 3.0 have been running it for several years now - i.e. it was the latest available at the time. Well, it was a stupid decision at that time, and the decision not to upgrade or replace these machines now is even stupider. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
Brian Somers [EMAIL PROTECTED] writes: Indeed. I've been doing a ``make build'' on an OpenBSD-current vm for three days (probably about 36 hours excluding suspends) on a 366MHz laptop with a ATA33 disk. Would it be possible for someone experiencing this slowdown to try to narrow down the day (or even the week) on which it occurred? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syscall kernel modules on 3.0-release
Matthew Emmerton [EMAIL PROTECTED] writes: I've got a 3.2-R machine which I'm forced to maintain, and the only reason why it's not running 3.2-S or 4.2-S is because I can't take the stupid thing offline. I've haggled with my boss for a 6 hour window and the answer is no, no, no. I've even got a 3.2-S installation waiting in /usr/obj. You don't need a six-hour window. Take a level 0 dump of the box, restore it on a scratch box, upgrade the scratch box and test it. If you can, write a script that does the entire upgrade. When you're sure you've got it down pat, take the production box down for however long you need to upgrade it (somewhere between half an hour and two hours depending on disk speeds and how much tinkering is needed). DES (been there, done that) -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
Julian Elischer [EMAIL PROTECTED] writes: I believe that vmware mmaps a region of memory and then somehow syncs it to disk. (It is certainly doing something like it here). Theory: VMWare mmaps a region of memory corresponding to the virtual machine's "physical" RAM, then touches every page during startup. Unless some form of clustering is done, this causes 16384 write operations for a 64 MB virtual machine... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
