Re: replacing grep(1)
"Brian F. Feldman" writes: > That's true. I'd like to see the replacement grep do mmaping of the > input files if it doesn't already, as that would speed it up. Shouldn't be too hard to implement, the way file operations are abstracted. Patches? :) DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
Sheldon Hearn 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 - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
Tim Vanderhoek writes: > Have you run your systems with J-grep as a replacement for GNU grep > for a while (making sure nothing breaks)? Yes. > There seems to be at least one dependency on GNU grep in > /ports/Mk/bsd.port.mk where the -F argument is used. -F is implemented. DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
/usr/share/man/man?/{i386|alpha}
Hello !
I am interesting about idea of directories man?/{i386|alpha}.
By their names I can understand that they are directories there
platform specific man pages for certain man section will be stored.
As I see there are only hard-linked manpages in man?/i386 directories. But
it's interesting -- will these directories be used in future for
storing unique (not hard-linked with other man pages) man pages ?
If so, then I can add some patches for makewhatis(1)/catman(1) while
I am working with internationalization support for this stuff.
PS: Yes, these utilities not contain functionality to understand
subdirectories in man directories.
--
Sincerely Yours, | phan...@crimea.edu (primary)
Alexey Zelkin | phan...@scorpion.crimea.ua (home)
| ICQ: #6196584, FIDO: 2:460/12.26
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Tue, 27 Jul 1999 22:20:40 MST, "David O'Brien" wrote: > My advice would be to submit his PR to Chris Demtrito(sp?), file's > maintainer. Then import NetBSD's file (Chris is a NetBSD guy). Hmmm. So file(1) is a contrib candidate? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Replace/rewrite reverse.c for tail(1)
An application I use quite often requires me to reverse the lines in the file to get the desired output. 'tail -r' appears to be very inefficient in it's use of mmap(). It mmap's the entire file in, which encourages the kernel to swap out the rest of the system to keep pages of the input file in memory. 58350 root 54 0 412M 85244K RUN 0:14 19.78% 19.19% tail Out of 128M of ram, it's swapped nearly everything else out to keep 85M of this 400M file in ram, even though it will never touch it again. :) I see two possible fixes for this. One could be madvise'ing periodically with MADV_DONTNEED. If I understand correctly, this would help a bit, right? Or, mmap smaller regions of the file, and keep moving the buffer. This would also help with files exceeding mmap's limits. Any thoughts? Kevin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Tue, 27 Jul 1999 22:20:40 MST, "David O'Brien" wrote: > > My advice would be to submit his PR to Chris Demtrito(sp?), file's > > maintainer. Then import NetBSD's file (Chris is a NetBSD guy). You may want to verify this. I'm pretty sure that Christos Zoulas (another NetBSD guy) maintains file(1): chris...@zoulas.com. - ad To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Wed, 28 Jul 1999 12:03:25 +0100, Andy Doran wrote: > You may want to verify this. I'm pretty sure that Christos Zoulas > (another NetBSD guy) maintains file(1): chris...@zoulas.com. Confirmed. Other than the mistaken name, I think David obsoleted further discussion, since it really is the best approach. :-) Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
newaliases and 256 tun devices
Hi ...
I previously mailed the same error ... and then I thought
it was a "miss-corrolation" between kernel sources and
userland. Since then I built a SNAP of 990726 sources
and tried the same thing and the error occured again .
Same sources used for the compile of the kernel and userlevel
binaries.
I've now traced the following down ... it has something todo
with the changes in net/if_dl.h (the entries added for
source routing and the fact that my kernel has
pseudo-device tun 255
in the config.
Setup.
PII400 / Asus P2-99 990726 SNAP / fxp and de0 cards.
When I do a "ifconfig fxp0 delete" and then a newaliases
the newaliases exits with a segmentation failt.
If I reconfig the device or up the device ... newaliases works
ok.
I then built a kernel with only 200 tun devices. Then newaliases
works everytime. It seems that gated also suffers from the same
problem in that if no device is configured it exits on signal 6
(core dumped)
Just for reference this works fine on a 2.2.7/8 FreeBSD without
any problems ...
The problem seems to be in conf.c of sendmail round line 4429
if there is 255 tun devices the for loop below only gets to
234 +/- and then doesn't check anything further and crashes
(but only if the working interface is deleted)
gdb shows that the pointer *sa points to somewhere wonderful :)
It must have something todo with the moving of this pointer
through the list ???
Was anything changed for the amount of tun devices allowed ??
for (i = 0; i < ifc.ifc_len; )
{
struct ifreq *ifr = (struct ifreq *) &ifc.ifc_buf[i];
SOCKADDR *sa = (SOCKADDR *) &ifr->ifr_addr;
struct in_addr ia;
#ifdef SIOCGIFFLAGS
struct ifreq ifrf;
#endif
char ip_addr[256];
extern char *inet_ntoa();
#ifdef BSD4_4_SOCKADDR
if (sa->sa.sa_len > sizeof ifr->ifr_addr)
i += sizeof ifr->ifr_name + sa->sa.sa_len;
else
#endif
i += sizeof *ifr;
if (tTd(0, 20))
printf("%s\n", anynet_ntoa(sa));
Thanx
Reinier
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: Free BSDI CD!
"Brian F. Feldman" 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 - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Wed, Jul 28, 1999 at 03:30:58AM -0400, Dag-Erling Smorgrav wrote: > > > There seems to be at least one dependency on GNU grep in > > /ports/Mk/bsd.port.mk where the -F argument is used. > > -F is implemented. I saw that, but had assumed the semantics were different. I should have read the read the manpages more closely: they're not. Sorry. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
/usr/src/sys/i386/boot/netboot problem during compile
I have a problem compiling of files needed for network boot on a FreeBSD 3.2-Release. As it was writen in handbook, I have to compile nb8390.com, nb3c509.com, nb8390.rom, nb3c509.rom files to perform boot over network. But during compile a I get the following error: /usr/src/sys/i386/boot/netboot > make Warning: Object directory not changed from original /usr/src/sys/i386/boot/netboot ln -s /usr/src/sys/i386/boot/netboot/../../include /usr/src/sys/i386/boot/netboot/machine cc -O2 -DNFS -DROMSIZE=16384 -DRELOC=0x9 -DPCI -DPCI_VENDOR=0x10ec -DPCI_DEVICE=0x8029 -DPCI_CLASS=0x02,0x00,0x00 -DASK_BOOT -aout -I/usr/src/sys/i386/boot/ netboot/../../.. -I/usr/src/sys/i386/boot/netboot -DROMSIZE=16384 -static -o makerom /usr/src/sys/i386/boot/netboot/makerom.c ld: scrt0.o: No such file or directory *** Error code 1 as I understand I need this file (scrt0.o) because netboot makes *com files only from a.out files, not from ELF. In sources I found where is this file compiled - /usr/src/lib/csu. But it will only compile if I manually set flag FREEBSD_AOUT. And even after this, compiling netboot gives me: ld: /usr/lib/scrt0.o: malformed input file (not rel or archive) *** Error code 1 Please write me what I am doing wrong, and how can I get this *.com and *.rom files neede for network boot? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Linear buffers in VESA screen modes
Andrew Gordon 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 - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: /usr/src/sys/i386/boot/netboot problem during compile
Dima wrote: > I have a problem compiling of files needed for network boot on a FreeBSD > 3.2-Release. > as I understand I need this file (scrt0.o) because netboot makes *com > files only from a.out files, not from ELF. In sources I found where is > this file compiled - /usr/src/lib/csu. But it will only compile if I > manually set flag FREEBSD_AOUT. And even after this, compiling netboot > gives me: > ld: /usr/lib/scrt0.o: malformed input file (not rel or archive) > *** Error code 1 > > Please write me what I am doing wrong, and how can I get this *.com and > *.rom files neede for network boot? This is legacy code which is being kept around until loader(8) supports equivalent functionality. For now, I suggest you use "etherboot" in the ports collection. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
POSIX threads question
HI everybody. I'm having a problem writing a multi-threaded application. As I understand from the mans, calls to read and write are synchronized through file-locks. Having looked through the source for libc_r I noticed that calls to printf and fprintf are also synchronized. The question is - why I am still having a problem calling fprintf(stderr, ... from multiple threads, the output is simply not written until I make a socond or a third call to fprintf. I have disabled buffering for stderr with setvbuf. Thank you in advance. --- Sent by InfoArt iMail http://www.infoart.ru; http://www.stars.ru To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, 28 Jul 1999, Brian F. Feldman wrote: > > > If it will get ALL of you to give it a rest, how about: > > > per-rule logging limits > > > logging limit raising > > > logging limit resetting > > > Which would all NOT affect the statistics? Separate statistics/logging counters is fine, but i don't need per-rule limits, a global limit is ok --> sysctl -w for raising and ipfw zerolog (or reset) for resetting. And then ... securelevel == 3 I think it is better NOT to permit 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile faster to avoid DoS > > > > We need more input from people who use the code, to make sure they don't > > depend on the current 'features', or can live with changes to them. If you can keep the foot print small i can live with it. > > > > Implementing it is the easy part, making sure it's the right thing to do > > is the hard part. Right! > > Well, the easy part is done, except for raising limits. Look: > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > ipfw: Entry 1 logging count reset. > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > > I think this feature should DEFINITELY go in. I'm going to clean it up some > (ip_fw.c itself), and then make a set of diffs for this feature. > Nice? :) Nice? Depends on the diffs AND the man page ;-) Henk. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: newaliases and 256 tun devices
If it's of any use, I have 300 tun devices in my home development
machine and have no problems with sendmail, but I have a tulip card
(de) rather than an Intel and haven't every ``ifconfig delete''d it.
> Hi ...
>
>
> I previously mailed the same error ... and then I thought
> it was a "miss-corrolation" between kernel sources and
> userland. Since then I built a SNAP of 990726 sources
> and tried the same thing and the error occured again .
>
> Same sources used for the compile of the kernel and userlevel
> binaries.
>
> I've now traced the following down ... it has something todo
> with the changes in net/if_dl.h (the entries added for
> source routing and the fact that my kernel has
> pseudo-device tun 255
> in the config.
>
> Setup.
> PII400 / Asus P2-99 990726 SNAP / fxp and de0 cards.
>
> When I do a "ifconfig fxp0 delete" and then a newaliases
> the newaliases exits with a segmentation failt.
> If I reconfig the device or up the device ... newaliases works
> ok.
>
> I then built a kernel with only 200 tun devices. Then newaliases
> works everytime. It seems that gated also suffers from the same
> problem in that if no device is configured it exits on signal 6
> (core dumped)
>
> Just for reference this works fine on a 2.2.7/8 FreeBSD without
> any problems ...
>
> The problem seems to be in conf.c of sendmail round line 4429
> if there is 255 tun devices the for loop below only gets to
> 234 +/- and then doesn't check anything further and crashes
> (but only if the working interface is deleted)
> gdb shows that the pointer *sa points to somewhere wonderful :)
> It must have something todo with the moving of this pointer
> through the list ???
>
> Was anything changed for the amount of tun devices allowed ??
>
> for (i = 0; i < ifc.ifc_len; )
> {
> struct ifreq *ifr = (struct ifreq *) &ifc.ifc_buf[i];
> SOCKADDR *sa = (SOCKADDR *) &ifr->ifr_addr;
> struct in_addr ia;
> #ifdef SIOCGIFFLAGS
> struct ifreq ifrf;
> #endif
> char ip_addr[256];
> extern char *inet_ntoa();
>
> #ifdef BSD4_4_SOCKADDR
> if (sa->sa.sa_len > sizeof ifr->ifr_addr)
> i += sizeof ifr->ifr_name + sa->sa.sa_len;
> else
> #endif
> i += sizeof *ifr;
>
> if (tTd(0, 20))
> printf("%s\n", anynet_ntoa(sa));
>
>
>
> Thanx
> Reinier
--
Brian
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Tue, 27 Jul 1999, Julian Elischer wrote: > a system wide limit and each rule's logging counter individually resetable > back to 0. > > So, what's your vote? > > ... Joe I vote for this too. Henk. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: Replace/rewrite reverse.c for tail(1)
I'd suggest that you use "tac" from GNU textutils. Charles -Original Message- From: Kevin Day [mailto:toa...@dragondata.com] Sent: Wednesday, July 28, 1999 3:09 AM To: hack...@freebsd.org Subject: Replace/rewrite reverse.c for tail(1) An application I use quite often requires me to reverse the lines in the file to get the desired output. 'tail -r' appears to be very inefficient in it's use of mmap(). It mmap's the entire file in, which encourages the kernel to swap out the rest of the system to keep pages of the input file in memory. 58350 root 54 0 412M 85244K RUN 0:14 19.78% 19.19% tail Out of 128M of ram, it's swapped nearly everything else out to keep 85M of this 400M file in ram, even though it will never touch it again. :) I see two possible fixes for this. One could be madvise'ing periodically with MADV_DONTNEED. If I understand correctly, this would help a bit, right? Or, mmap smaller regions of the file, and keep moving the buffer. This would also help with files exceeding mmap's limits. Any thoughts? Kevin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Pasting data between terminals
Krzysztof Krawczyk wrote: > When I do: > echo "blah blah" >>/dev/ttyp1 > text "blah blah" appear in virtual terminal ttyp1, but only as a text of > "message". I need ttyp1 count those datas as a "command typed by hand", > not just a text displayed in this term as info. I must transport lots of > data between these terminals. Have you any ideas? have you tried using a pseudo-terminal? see pty(4) -- Tom Uffner t...@wact.net Themes were useless! Destiny was here and the foot pedals were bleeding! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> And then ... securelevel == 3 I think it is better NOT to permit > 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile > faster to avoid DoS The real issue we are dealing with is what happens at securelevel == 3. What you are saying is that people shouldn't be allowed to modify *anything* at securelevel == 3, correct? Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > Implementing it is the easy part, making sure it's the right thing to do > > is the hard part. > > Well, the easy part is done, except for raising limits. Look: > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > ipfw: Entry 1 logging count reset. > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > > Nice? :) Depends on how it effects the speed of the system and if it makes the code too complex. :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
In message <19990727214451.a66...@dragon.nuxi.com> "David O'Brien" writes: : Before importing, it must display a version number of 1.0 (or drop the : version number). This is not Linux where everything is version 0.xy. For a long time the new boot loader was in the tree with a version 0.xx... Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/12852: Non-standard behavior of fread(3)
Hi folks, Could someone have a look at the patch proposed on PR 12852? I understand the motivation, since it seems reasonable to me that ferror() should return EBADF after an attempt to read from stdout. At the moment, ferror() returns 0 after an attempt to read from stdout. Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
> > > My advice would be to submit his PR to Chris Demtrito(sp?), file's > > You may want to verify this. I'm pretty sure that Christos Zoulas > (another NetBSD guy) maintains file(1): chris...@zoulas.com. My major Duh!! If Christos sees this thread, my apologies. There is no excuse for me not checking the source to make sure I was accurate before opening my mouth. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
James Howard wrote: > > Due to the discussion of speed, I have been looking at it and it is really > slow. Even slower than I thought and I was thinking it was pretty slow. > > So using gprof, I have discovered that it seems to spend a whole mess of > time in grep_malloc() and free(). So I pulled all the references to > malloc inside the main loop (the copy for ln.dat and removed queueing). > This stills leaves us with a grep that is about ~6x slower than GNU. > Before that, it ran closer to 80x. After this, gprof says it spends > around 53% of its time in procline(). Sorry, but a simplistic analysis like that just won't cut for grep. The algorithmic complexity is highly relevant here. Try this: generate a 1 Mb file, and then generate 10 Mb and 50 Mb files by concatenating that first file. Benchmark yours and GNU grep a number of times to get the average for each file. Now compare the *proportions* between the different sized files. Are they the same? Next, try different sized patterns on the 50 Mb file on both yours and GNU grep. Again, compare the proportion. Next, compare patterns with different number of "wildcards", patterns with things like [acegikmoqsuvxz] vs [acegikmoqsuvxzACEGIKMOQSUVXZ], etc. Either that, or do a complexity analysis of the algorithms. :-) (In case anyone reading this discussion wants to know more about complexity of algorithms, I recommend Computer Algorithms, Introduction to Design and Analysis, by Sara Baase, Addison Wesley.) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
I expect that there is a very good reason why this shouldn't be done, but could it be possible to implement two different algorithms/code dependant on the size of the file being grepped? Mark Dickey m...@bestweb.net Daniel C. Sobral wrote: > James Howard wrote: > > > > Due to the discussion of speed, I have been looking at it and it is really > > slow. Even slower than I thought and I was thinking it was pretty slow. > > > > So using gprof, I have discovered that it seems to spend a whole mess of > > time in grep_malloc() and free(). So I pulled all the references to > > malloc inside the main loop (the copy for ln.dat and removed queueing). > > This stills leaves us with a grep that is about ~6x slower than GNU. > > Before that, it ran closer to 80x. After this, gprof says it spends > > around 53% of its time in procline(). > > Sorry, but a simplistic analysis like that just won't cut for grep. > The algorithmic complexity is highly relevant here. Try this: > generate a 1 Mb file, and then generate 10 Mb and 50 Mb files by > concatenating that first file. Benchmark yours and GNU grep a number > of times to get the average for each file. Now compare the > *proportions* between the different sized files. Are they the same? > > Next, try different sized patterns on the 50 Mb file on both yours > and GNU grep. Again, compare the proportion. > > Next, compare patterns with different number of "wildcards", > patterns with things like [acegikmoqsuvxz] vs > [acegikmoqsuvxzACEGIKMOQSUVXZ], etc. > > Either that, or do a complexity analysis of the algorithms. :-) > > (In case anyone reading this discussion wants to know more about > complexity of algorithms, I recommend Computer Algorithms, > Introduction to Design and Analysis, by Sara Baase, Addison Wesley.) > > -- > Daniel C. Sobral (8-DCS) > d...@newsguy.com > d...@freebsd.org > > "Is it true that you're a millionaire's son who never worked a day > in your life?" > "Yeah, I guess so." > "Lemme tell you, son, you ain't missed a thing." > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/12852: Non-standard behavior of fread(3)
Sheldon Hearn wrote:
> Could someone have a look at the patch proposed on PR 12852? I
> understand the motivation, since it seems reasonable to me that ferror()
> should return EBADF after an attempt to read from stdout. At the moment,
> ferror() returns 0 after an attempt to read from stdout.
There's no question this needs changing. An ISO example actually
reads along the lines of:
while (!feof(fp) && !ferror(fp))
fscanf(fp, ...);
with no further provision for error-detection. Applied to stdout,
this never terminates.
The SVID wording is more definite than ISO in discussing this ("less
than nitems only if a read error or end-of-file is encountered"),
but mostly the present behavior just conflicts with sense and
practice.
--
Robert Nordier
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: Free BSDI CD!
On 28 Jul 1999, Dag-Erling Smorgrav wrote: > "Brian F. Feldman" 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. Those are the only times I have. It's much faster than, say, downloading an NT service pack and hotfixes, or "windos updating", if that's who we're supposed to be competing with in the server market. > > DES > -- > Dag-Erling Smorgrav - d...@flood.ping.uio.no > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Tue, 27 Jul 1999, Brian F. Feldman wrote: > If it will get ALL of you to give it a rest, how about: > per-rule logging limits This has been needed for some time now. Also, please don't forget the oft-repeated request to have seperate accounting and logging counters so that you can zero one, but not the other. > logging limit raising > logging limit resetting I'd say that these are good knobs to have (I assume you're talking sysctl's?) but I'd also like to suggest a knob that allows you to toggle whether these can be changed at securelevel > 1, which knob is not resettable at securelevel > 1. I think that this would answer the needs of all parties concerned. > Which would all NOT affect the statistics? Oh good, you didn't forget. :) > I am, yes, suggesting I will implement it. Coolio. And inre the request to hear from the users of the code, I am one, have been for years, and deploy it in many different environments (including natd, basic security, etc.). These would be very welcome additions assuming that the performance hit is negligible. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, 28 Jul 1999, Nate Williams wrote: > > > Implementing it is the easy part, making sure it's the right thing to do > > > is the hard part. > > > > Well, the easy part is done, except for raising limits. Look: > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > ipfw: limit 2 reached on rule #1 > > ipfw: Entry 1 logging count reset. > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > ipfw: limit 2 reached on rule #1 > > > > Nice? :) > > Depends on how it effects the speed of the system and if it makes the > code too complex. :) None and no. > > > Nate > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > > Implementing it is the easy part, making sure it's the right thing to do > > > > is the hard part. > > > > > > Well, the easy part is done, except for raising limits. Look: > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: limit 2 reached on rule #1 > > > ipfw: Entry 1 logging count reset. > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: limit 2 reached on rule #1 > > > > > > Nice? :) > > > > Depends on how it effects the speed of the system and if it makes the > > code too complex. :) > > None and no. Beauty is in the eye of the beholder. Let's suspend judgement on it until we actually get a chance to review it, pride in your work not withstanding. :) :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Was someone looking for a BSD licensed stat(1)?
I hacked this together last night. The only GNU code I looked at was the
Linux stat(1u) man page. (A man page is forthcoming, especially if there is
some interest in using this implementation.) The code is also available at
http://www.kagekaze.org/stat.c
Regards,
--Keith Stevenson--
--
Keith Stevenson
System Programmer - Data Center Services - University of Louisville
k.steven...@louisville.edu
PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0
/* stat.c: Human readable interface to stat(2) system call */
/*-
* Copyright (c) 1999 Keith Stevenson
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $Id: stat.c,v 1.2 1999/07/28 19:33:10 ktstev01 Exp $
*/
#ifndef lint
static const char copyright[] =
"Copyright (c) 1999\nKeith Stevenson. All rights reserved.\n";
static const char rcsid[] =
"$Id: stat.c,v 1.2 1999/07/28 19:33:10 ktstev01 Exp $";
#endif /* not lint */
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* stat: Display the contents of an inode in a human friendly format. */
int
main(int argc, char *argv[])
{
charftype[20];
charfmode[11];
int count;
struct group*gp;
struct passwd *pw;
struct stat inode;
struct tm *atime, *mtime, *ctime;
for (count = 1; count < argc; count++) {
if (lstat(argv[count], &inode) != -1) {
/* Initialize */
memset(fmode, '-', sizeof(fmode));
fmode[10] = '\0';
/* Interpret file type */
switch (inode.st_mode & S_IFMT) {
case S_IFIFO:
strncpy(ftype, "FIFO", sizeof(ftype));
fmode[0] = 'p';
break;
case S_IFCHR:
strncpy(ftype, "Character Special",
sizeof(ftype));
fmode[0] = 'c';
break;
case S_IFDIR:
strncpy(ftype, "Directory", sizeof(ftype));
fmode[0] = 'd';
break;
case S_IFBLK:
strncpy(ftype, "Block Special", sizeof(ftype));
fmode[0] = 'b';
break;
case S_IFREG:
strncpy(ftype, "Regular", sizeof(ftype));
break;
case S_IFLNK:
strncpy(ftype, "Symbolic Link", sizeof(ftype));
fmode[0] = 'l';
break;
case S_IFSOCK:
strncpy(ftype, "Socket", sizeof(ftype));
fmode[0] = 's';
break;
case S_IFWHT:
strncpy(ftype, "Whiteout", sizeof(ftype));
fmode[0] = '?';
break;
default:
strncpy(ftype, "Unknown", sizeof(ftype));
fmode[0] = '?';
break;
}
/* Interpret file mode */
if (inode.st_mode & S_IRUSR)
fmode[1] = 'r';
if (inode.st_mode & S_IWUSR)
Re: securelevel and ipfw zero
I need help finishing it. The ipfw.8 manpage isn't quite fixed yet. When
someone will do that, it will be Ready :) But I've attached it!
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
Index: src/sbin/ipfw/ipfw.8
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw.8,v
retrieving revision 1.54
diff -u -r1.54 ipfw.8
--- ipfw.8 1999/06/19 18:43:18 1.54
+++ ipfw.8 1999/07/28 19:35:31
@@ -50,6 +50,7 @@
.Op Ar number
.Ar action
.Op log
+.Op Ar logamount Ar number
.Ar proto
from
.Ar src
Index: src/sbin/ipfw/ipfw.c
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw.c,v
retrieving revision 1.71
diff -u -r1.71 ipfw.c
--- ipfw.c 1999/06/19 18:43:15 1.71
+++ ipfw.c 1999/07/28 06:15:08
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -247,8 +248,11 @@
errx(EX_OSERR, "impossible");
}
- if (chain->fw_flg & IP_FW_F_PRN)
+ if (chain->fw_flg & IP_FW_F_PRN) {
printf(" log");
+ if (chain->fw_logamount)
+ printf(" logamount %d", chain->fw_logamount);
+ }
pe = getprotobynumber(chain->fw_prot);
if (pe)
@@ -599,12 +603,13 @@
"[pipe] list [number ...]\n"
"[pipe] show [number ...]\n"
"zero [number ...]\n"
+"resetlog [number ...]\n"
"pipe number config [pipeconfig]\n"
" rule: action proto src dst extras...\n"
"action:\n"
" {allow|permit|accept|pass|deny|drop|reject|unreach code|\n"
" reset|count|skipto num|divert port|tee port|fwd ip|\n"
-" pipe num} [log]\n"
+" pipe num} [log [logamount count]]\n"
"proto: {ip|tcp|udp|icmp|}\n"
"src: from [not] {any|ip[{/bits|:mask}]} [{port|port-port},[port],...]\n"
"dst: to [not] {any|ip[{/bits|:mask}]} [{port|port-port},[port],...]\n"
@@ -1164,6 +1169,18 @@
if (ac && !strncmp(*av,"log",strlen(*av))) {
rule.fw_flg |= IP_FW_F_PRN; av++; ac--;
}
+ if (ac && !strncmp(*av,"logamount",strlen(*av))) {
+ if (!(rule.fw_flg & IP_FW_F_PRN))
+ show_usage("``logamount'' not valid without ``log''");
+ ac--; av++;
+ if (!ac)
+ show_usage("``logamount'' requires argument");
+ rule.fw_logamount = atoi(*av);
+ if (rule.fw_logamount <= 0)
+ show_usage("``logamount'' argument must be greater "
+ "than 0");
+ ac--; av++;
+ }
/* protocol */
if (ac == 0)
@@ -1385,7 +1402,18 @@
if (rule.fw_nports)
show_usage("can't mix 'frag' and port specifications");
}
-
+ if (rule.fw_flg & IP_FW_F_PRN) {
+ if (!rule.fw_logamount) {
+ size_t len = sizeof(int);
+
+ if (sysctlbyname("net.inet.ip.fw.verbose_limit",
+ &rule.fw_logamount, &len, NULL, 0) == -1)
+ errx(1, "sysctlbyname(\"%s\")",
+ "net.inet.ip.fw.verbose_limit");
+ }
+ rule.fw_loghighest = rule.fw_logamount;
+ }
+
if (!do_quiet)
show_ipfw(&rule, 10, 10);
i = setsockopt(s, IPPROTO_IP, IP_FW_ADD, &rule, sizeof rule);
@@ -1432,6 +1460,45 @@
}
}
+static void
+resetlog (ac, av)
+ int ac;
+ char **av;
+{
+ av++; ac--;
+
+ if (!ac) {
+ /* clear all entries */
+ if (setsockopt(s,IPPROTO_IP,IP_FW_RESETLOG,NULL,0)<0)
+ err(EX_UNAVAILABLE, "setsockopt(%s)", "IP_FW_RESETLOG");
+ if (!do_quiet)
+ printf("Logging counts reset.\n");
+ } else {
+ struct ip_fw rule;
+ int failed = EX_OK;
+
+ memset(&rule, 0, sizeof rule);
+ while (ac) {
+ /* Rule number */
+ if (isdigit(**av)) {
+ rule.fw_number = atoi(*av); av++; ac--;
+ if (setsockopt(s, IPPROTO_IP,
+ IP_FW_RESETLOG, &rule, sizeof rule)) {
+ warn("rule %u: setsockopt(%s)",
rule.fw_number,
+"IP_FW_RESETLOG");
+ failed = EX_UNAVAILABLE;
+ }
+ else if (!do_quiet)
+ printf("Entry %d logging count reset\n",
+
Re: securelevel and ipfw zero
> Index: src/sys/netinet/ip_fw.c
> ===
> RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> retrieving revision 1.114
> diff -u -r1.114 ip_fw.c
> --- ip_fw.c 1999/06/19 18:43:28 1.114
> +++ ip_fw.c 1999/07/28 06:29:07
> @@ -106,6 +106,7 @@
> static int add_entry __P((struct ip_fw_head *chainptr, struct ip_fw
> *frwl));
> static int del_entry __P((struct ip_fw_head *chainptr, u_short number));
> static int zero_entry __P((struct ip_fw *));
> +static int resetlog_entry __P((struct ip_fw *));
> static int check_ipfw_struct __P((struct ip_fw *m));
> static __inline int
> iface_match __P((struct ifnet *ifp, union ip_fw_if *ifu,
> @@ -184,8 +185,8 @@
>
> /* check for matching type in the bitmap */
> if (type < IP_FW_ICMPTYPES_MAX &&
> - (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * 8)] &
> - (1U << (type % (8 * sizeof(unsigned))
> + (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * NBBY)] &
> + (1U << (type % (sizeof(unsigned) * NBBY)
> return(1);
>
> return(0); /* no match */
These are good bugfixes, and should be committed seperately.
> @@ -302,14 +303,15 @@
> struct ifnet *rif, struct ifnet *oif)
> {
> if (ip) {
> + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl);
> + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl);
> + struct icmp *const icmp = (struct icmp *)((u_int32_t *)ip+ip->ip_hl);
> static u_int64_t counter;
> - struct tcphdr *const tcp = (struct tcphdr *) ((u_int32_t *) ip+
> ip->ip_hl);
> - struct udphdr *const udp = (struct udphdr *) ((u_int32_t *) ip+
> ip->ip_hl);
> - struct icmp *const icmp = (struct icmp *) ((u_int32_t *) ip +
> ip->ip_hl);
> - int count;
> + u_int64_t count;
These are mostly change for changes sake, and make it difficult to see
the functional changes. Please limit your changes to changes, and not
just to add stylistic differences. While I may agree with them, they
detract from the review process.
[ Rest deleted ]
Can you resend them to me in private email after you remove the
white-space/stylistic changes? Thanks!
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: Was someone looking for a BSD licensed stat(1)?
Since you've got it in RCS, you shouldn't have any problem adding new
features. How about a selectable display of fields, and ability to put
them in machine-readable (read: no cut required) form? I'd suggest
having a function that would printf "%s: whatever", arg1 for humans
and "whatever" for machines, selectable by something like a -c
"compact output flag." Here's the GPLd stat I have:
{"/usr"}# stat
stat [-cihsv] [-o opts] [-f file] [filename ...]
-h this help
-v verbose output
-c compact output
-i ignore errors
-s stop on error
-f read filenames to be stat-ed from file (- means stdin)
-d dereference symbolic links.
-o opts output options (case insensitive):
a access time
c creation time
d device
g group
i inode
l links
m mode
n file name
o modification time
s size
t type
u owner
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Documenting writev(2) ENOBUFS error
-hackers, Could someone who knows write/writev(2) take a quick look at docs/10512. In essence, writev(2) can fail with ENOBUFS if (and I quote from the PR) if you "exhaust writev'able buffer space". This doesn't mean a great deal to me, and I'm hoping one of you can take a look at come up with a phrasing suitable for a man page. Cheers, N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Including isa/isareg.h in sys/i386/boot/biosboot/serial.S
-hackers, In the kernel config file you can use symbolic names for the various COM ports, IO_COM1, IO_COM2, and so on. These seem be defined in sys/isa/isareg.h. If you want to configure FreeBSD to boot from a serial console you have to set BOOT_COMCONSOLE_PORT in /etc/make.conf -- you can't use the defines here, you have to use 0x3F8, 0x2F8, and so on. As far as I can tell, BOOT_COMCONSOLE_PORT eventually gets passed down to sys/i386/boot/biosboot/serial.S. So, why not apply the following trivial patch to serial.S, so that /etc/make.conf can instead contain BOOT_COMCONSOLE_PORT= IO_COM2 which is just slightly friendlier? I'm not what you'd call a kernel hacker, so this might be a stupid idea. . . N Index: serial.S === RCS file: /home/ncvs/src/sys/i386/boot/biosboot/serial.S,v retrieving revision 1.12 diff -u -1 -r1.12 serial.S --- serial.S1999/04/22 21:02:44 1.12 +++ serial.S1999/07/28 14:30:54 @@ -70,2 +70,3 @@ #include +#include #include "asm.h" -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Will FreeBSD ever see native IPv6 ??
On Tue, Jul 27, 1999 at 10:58:08PM -0700, David O'Brien wrote: > Lets help these people out. How about adding this to 3.3's RELEASE notes > and a pointer from our website? (maybe also > http://www.freebsd.org/handbook/install.html) If you can give me text, I'll mark it up and add it. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, 28 Jul 1999, Nate Williams wrote:
> > Index: src/sys/netinet/ip_fw.c
> > ===
> > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> > retrieving revision 1.114
> > diff -u -r1.114 ip_fw.c
> > --- ip_fw.c 1999/06/19 18:43:28 1.114
> > +++ ip_fw.c 1999/07/28 06:29:07
> > @@ -106,6 +106,7 @@
> > static int add_entry __P((struct ip_fw_head *chainptr, struct ip_fw
> > *frwl));
> > static int del_entry __P((struct ip_fw_head *chainptr, u_short number));
> > static int zero_entry __P((struct ip_fw *));
> > +static int resetlog_entry __P((struct ip_fw *));
> > static int check_ipfw_struct __P((struct ip_fw *m));
> > static __inline int
> > iface_match __P((struct ifnet *ifp, union ip_fw_if *ifu,
> > @@ -184,8 +185,8 @@
> >
> > /* check for matching type in the bitmap */
> > if (type < IP_FW_ICMPTYPES_MAX &&
> > - (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * 8)] &
> > - (1U << (type % (8 * sizeof(unsigned))
> > + (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * NBBY)] &
> > +(1U << (type % (sizeof(unsigned) * NBBY)
> > return(1);
> >
> > return(0); /* no match */
>
> These are good bugfixes, and should be committed seperately.
Yes, this specific part shouldn't go in the same commit.
>
> > @@ -302,14 +303,15 @@
> > struct ifnet *rif, struct ifnet *oif)
> > {
> > if (ip) {
> > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl);
> > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl);
> > + struct icmp *const icmp = (struct icmp *)((u_int32_t *)ip+ip->ip_hl);
> > static u_int64_t counter;
> > - struct tcphdr *const tcp = (struct tcphdr *) ((u_int32_t *) ip+
> > ip->ip_hl);
> > - struct udphdr *const udp = (struct udphdr *) ((u_int32_t *) ip+
> > ip->ip_hl);
> > - struct icmp *const icmp = (struct icmp *) ((u_int32_t *) ip +
> > ip->ip_hl);
> > - int count;
> > + u_int64_t count;
>
> These are mostly change for changes sake, and make it difficult to see
> the functional changes. Please limit your changes to changes, and not
> just to add stylistic differences. While I may agree with them, they
> detract from the review process.
These were changes that were necessary to make ipfw readable enough that
I could work with it in this area. They aren't just to clean it up, or
just for change's sake. They need to stay in.
>
> [ Rest deleted ]
>
> Can you resend them to me in private email after you remove the
> white-space/stylistic changes? Thanks!
>
>
>
> Nate
>
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > @@ -302,14 +303,15 @@
> > > struct ifnet *rif, struct ifnet *oif)
> > > {
> > > if (ip) {
> > > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct icmp *const icmp = (struct icmp *)((u_int32_t *)ip+ip->ip_hl);
> > > static u_int64_t counter;
> > > - struct tcphdr *const tcp = (struct tcphdr *) ((u_int32_t *) ip+
> > > ip->ip_hl);
> > > - struct udphdr *const udp = (struct udphdr *) ((u_int32_t *) ip+
> > > ip->ip_hl);
> > > - struct icmp *const icmp = (struct icmp *) ((u_int32_t *) ip +
> > > ip->ip_hl);
> > > - int count;
> > > + u_int64_t count;
> >
> > These are mostly change for changes sake, and make it difficult to see
> > the functional changes. Please limit your changes to changes, and not
> > just to add stylistic differences. While I may agree with them, they
> > detract from the review process.
>
> These were changes that were necessary to make ipfw readable enough that
> I could work with it in this area. They aren't just to clean it up, or
> just for change's sake. They need to stay in.
C'mon now, re-ording the lines is *certainly* not necessary to work.
*rant on*
Brian, FreeBSD isn't your private playground for playing around, this is
a group project, and you gotta follow the rules, or you don't get to
play with the rest of the folks
*rant off*
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, 28 Jul 1999, Nate Williams wrote: > > > > These were changes that were necessary to make ipfw readable enough that > > I could work with it in this area. They aren't just to clean it up, or > > just for change's sake. They need to stay in. > > C'mon now, re-ording the lines is *certainly* not necessary to work. That's true. I sure didn't do that. > > *rant on* > Brian, FreeBSD isn't your private playground for playing around, this is > a group project, and you gotta follow the rules, or you don't get to > play with the rest of the folks The rules don't say "leave the code that you work with in a bigger mess than when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be done to get work done, very often. You have to learn to deal with that. > *rant off* > > > > > Nate > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > These were changes that were necessary to make ipfw readable enough that > > > I could work with it in this area. They aren't just to clean it up, or > > > just for change's sake. They need to stay in. > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > That's true. I sure didn't do that. Sure looks like you did. There are white-space and re-ordering modifications in the diffs you sent out. If you didn't do them, who did? > > *rant on* > > Brian, FreeBSD isn't your private playground for playing around, this is > > a group project, and you gotta follow the rules, or you don't get to > > play with the rest of the folks > > The rules don't say "leave the code that you work with in a bigger mess than > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > done to get work done, very often. You have to learn to deal with that. No, cleanups occur *separately* from code additions. The code is *very* readable now, and just because you have stylistic differences doesn't mean you get to change them because you like them. In particular, the changes I pointed out are not 'cleanups', but style changes. I repeat, this isn't your personal playground. Play by the rules or don't play at all. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Was someone looking for a BSD licensed stat(1)?
On Wed, Jul 28, 1999 at 04:01:10PM -0400, Brian F. Feldman wrote: > Since you've got it in RCS, you shouldn't have any problem adding new > features. How about a selectable display of fields, and ability to put > them in machine-readable (read: no cut required) form? I'd suggest > having a function that would printf "%s: whatever", arg1 for humans > and "whatever" for machines, selectable by something like a -c > "compact output flag." Here's the GPLd stat I have: > Sure, I can work on that. It would be helpful if you could include a few sample outputs that I could work from. The current version already solves my problems, but I'll be happy to hack away at it if you are interested in including it in FreeBSD in some way. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, 28 Jul 1999, Brian F. Feldman wrote: > On Wed, 28 Jul 1999, Nate Williams wrote: > > > > > > These were changes that were necessary to make ipfw readable enough that > > > I could work with it in this area. They aren't just to clean it up, or > > > just for change's sake. They need to stay in. > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > That's true. I sure didn't do that. > > > > > *rant on* > > Brian, FreeBSD isn't your private playground for playing around, this is > > a group project, and you gotta follow the rules, or you don't get to > > play with the rest of the folks > > The rules don't say "leave the code that you work with in a bigger mess than > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > done to get work done, very often. You have to learn to deal with that. > > > *rant off* and so it should remain, changes that provide readability to code should be committed, the only time documentation of code is wrong is when it it is incorrect. Increasing the size of the cvs repo is not a consideration when worthwhile docs can be incorperated, especially when the person who needs to maintain it requires changess for readability. Is there a point to hindering the maintainer's ongoing work? -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, 28 Jul 1999, Nate Williams wrote: > > > > These were changes that were necessary to make ipfw readable enough that > > > > I could work with it in this area. They aren't just to clean it up, or > > > > just for change's sake. They need to stay in. > > > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > > > That's true. I sure didn't do that. > > Sure looks like you did. There are white-space and re-ordering > modifications in the diffs you sent out. If you didn't do them, who > did? I refuse to justify putting variables in a function I changed in the right place. > > > > *rant on* > > > Brian, FreeBSD isn't your private playground for playing around, this is > > > a group project, and you gotta follow the rules, or you don't get to > > > play with the rest of the folks > > > > The rules don't say "leave the code that you work with in a bigger mess than > > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > > done to get work done, very often. You have to learn to deal with that. > > No, cleanups occur *separately* from code additions. The code is *very* > readable now, and just because you have stylistic differences doesn't > mean you get to change them because you like them. Stylistic differences my ass. This module (ip_fw) breaks style(9) in so many ways, it's not funny. It's sad. > > In particular, the changes I pointed out are not 'cleanups', but style > changes. When you make code readable, it's a cleanup. > > I repeat, this isn't your personal playground. Play by the rules or > don't play at all. "Follow KNF or stay out of the kernel code." > > > Nate > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > *rant on* > > > Brian, FreeBSD isn't your private playground for playing around, this is > > > a group project, and you gotta follow the rules, or you don't get to > > > play with the rest of the folks > > > > The rules don't say "leave the code that you work with in a bigger mess than > > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > > done to get work done, very often. You have to learn to deal with that. > > > > > *rant off* > > and so it should remain, changes that provide readability to > code should be committed, the only time documentation of code > is wrong is when it it is incorrect. The changes pointed out do *NOT* make the code more readable. They just move statements around for no reason, and change whitespace. > Increasing the size of the cvs repo is not a consideration when > worthwhile docs can be incorperated, especially when the person > who needs to maintain it requires changess for readability. Brian is *NOT* the maintainer, he is the author of a patch to it. Doesn't anyone care for keeping the source code consistant *AND* maintainable for multiple people, as well as maintaining a history of *CHANGES* for people to review in the future? Or is this Linux, where we don't give a rip and whatever the current patch does to the rest of the tree is fine, since the more code we have the better? Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > > > These were changes that were necessary to make ipfw readable enough > > > > > that > > > > > I could work with it in this area. They aren't just to clean it up, or > > > > > just for change's sake. They need to stay in. > > > > > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > > > > > That's true. I sure didn't do that. > > > > Sure looks like you did. There are white-space and re-ordering > > modifications in the diffs you sent out. If you didn't do them, who > > did? > > I refuse to justify putting variables in a function I changed in the > right place. This and other obnoxious responses to valid responses makes me want to ask for your commit privileges. You obviously don't care what anyone else has done. > > In particular, the changes I pointed out are not 'cleanups', but style > > changes. > > When you make code readable, it's a cleanup. The code is *NO* more readable by you re-ordering lines and changes whitespace. Grow up and quit acting like a child who doesn't wanna follow the rules. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, 28 Jul 1999, Nate Williams wrote: > > > > *rant on* > > > > Brian, FreeBSD isn't your private playground for playing around, this is > > > > a group project, and you gotta follow the rules, or you don't get to > > > > play with the rest of the folks > > > > > > The rules don't say "leave the code that you work with in a bigger mess > > > than > > > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to > > > be > > > done to get work done, very often. You have to learn to deal with that. > > > > > > > *rant off* > > > > and so it should remain, changes that provide readability to > > code should be committed, the only time documentation of code > > is wrong is when it it is incorrect. > > The changes pointed out do *NOT* make the code more readable. They just > move statements around for no reason, and change whitespace. It makes it more readable if you understand and use KNF instead of try to bastardize everyone else's code. > > > Increasing the size of the cvs repo is not a consideration when > > worthwhile docs can be incorperated, especially when the person > > who needs to maintain it requires changess for readability. > > Brian is *NOT* the maintainer, he is the author of a patch to it. I'm one of the people who actively works on it. Who are you? > > Doesn't anyone care for keeping the source code consistant *AND* > maintainable for multiple people, as well as maintaining a history of > *CHANGES* for people to review in the future? What do you think KNF is about? I'll bring out the big guns now (BDE). > > Or is this Linux, where we don't give a rip and whatever the current > patch does to the rest of the tree is fine, since the more code we have > the better? > You have no idea what you're talking about, WRT FreeBSD. > > > Nate > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Including isa/isareg.h in sys/i386/boot/biosboot/serial.S
> In the kernel config file you can use symbolic names for the various > COM ports, IO_COM1, IO_COM2, and so on. > > These seem be defined in sys/isa/isareg.h. > > If you want to configure FreeBSD to boot from a serial console you have > to set BOOT_COMCONSOLE_PORT in /etc/make.conf -- you can't use the > defines here, you have to use 0x3F8, 0x2F8, and so on. > > As far as I can tell, BOOT_COMCONSOLE_PORT eventually gets passed down > to sys/i386/boot/biosboot/serial.S. > > So, why not apply the following trivial patch to serial.S, so that > /etc/make.conf can instead contain > > BOOT_COMCONSOLE_PORT= IO_COM2 > > which is just slightly friendlier? I'm not what you'd call a kernel > hacker, so this might be a stupid idea. . . The sys/i386/boot/biosboot code is going away shortly. The corresponding non-legacy code is sys/boot/i386/boot2, though there are various other places in the new boot code this is used as well: kgzldr and libi386, for the i386. A suggestion similar to yours was discussed off the lists around seven months ago, but the majority view was that the perceived advantages didn't completely justify the required changes and potential confusion. Since the boot code works with the BIOS, the early binding of COM2 to 0x2f8 is probably not justified. COM2 could -- and maybe should -- mean "the port BIOS is using for COM2" which may be something quite different than 0x2f8. There's actually a fairly loose coupling between the kernel and the boot code, and making use of kernel configuration conventions, where the semantics may end up being just slightly different, is probably a less useful idea than it seems. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, 28 Jul 1999, Nate Williams wrote: > > > > > > These were changes that were necessary to make ipfw readable enough > > > > > > that > > > > > > I could work with it in this area. They aren't just to clean it up, > > > > > > or > > > > > > just for change's sake. They need to stay in. > > > > > > > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > > > > > > > That's true. I sure didn't do that. > > > > > > Sure looks like you did. There are white-space and re-ordering > > > modifications in the diffs you sent out. If you didn't do them, who > > > did? > > > > I refuse to justify putting variables in a function I changed in the > > right place. > > This and other obnoxious responses to valid responses makes me want to > ask for your commit privileges. You obviously don't care what anyone > else has done. > > > > In particular, the changes I pointed out are not 'cleanups', but style > > > changes. > > > > When you make code readable, it's a cleanup. > > The code is *NO* more readable by you re-ordering lines and changes > whitespace. This is so very objective. > > Grow up and quit acting like a child who doesn't wanna follow the rules. quit acting like and old fart that fears change. (*) afaik, Brian is the mainter of ipfw, it should be noted so, so that if his changes break something it comes down on his head. Trust me to say something if that occurs. I'm no big friend of Brian, however changes to correct readability should be welcome especially to the maintainer. -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ (*) if you don't like "old fart" then choose to play the age card with a bit more thought, there are many other commiters that fall under your catagorization. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > > In particular, the changes I pointed out are not 'cleanups', but style > > > > changes. > > > > > > When you make code readable, it's a cleanup. > > > > The code is *NO* more readable by you re-ordering lines and changes > > whitespace. > > This is so very objective. That's why it considered a 'stylistic' change, and not a functional change. And, that's why stylistic changes are not allowed to be mixed with functional changes. I quote from a recent article involving Brian early last week. -- From: "Jordan K. Hubbard" Subject: Re: cvs commit: src/usr.sbin/inetd builtins.c Date: Fri, 23 Jul 1999 19:25:26 -0700 > > I realize that stack space is not really an issue. Do you think I care > > about the possible savings of a few bytes? The issue is that variables > > should be declared _in_the_proper_places_, so that's where they go in > > my code. And yes, this is my code. I didn't appreciate Sheldon "restyling" > > it, because that makes it harder for /me/ to maintain. > > Having your own private coding style is arguably OK; using it > in other's code is definitely not. Please stick to the coding style > of the module you are editing. Actually, I hadn't even considered that point but Mark's entirely correct. You don't get to pick your own style in the middle of code that someone else has written, you stick to the SAME style even if it's totally style(9) non-conformant and icky in the extreme. -- You don't get to change styles even if it's non-conformant. > > Grow up and quit acting like a child who doesn't wanna follow the rules. > > quit acting like and old fart that fears change. (*) Fears change? Not quite. I was willing to write the necessary changes myself if necessary (see previous email on this thread), but I wanted to make sure it was both desirable (beyond one's person POV), as well as it wouldn't negatively effect other users of the system. > afaik, Brian is the mainter of ipfw, it should be noted so, so that > if his changes break something it comes down on his head. Trust > me to say something if that occurs. Brian is *NOT* the maintainer of IPFW, and thinking that is silliness. If you think that, then you're confused. Being the last person to commit something doesn't make you the committer, and even more so committing one change to the code doesn't make you the committer. I've committed two things to it, so I win by default in that case. :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
Doug wrote: > The more complete the feature set, the better >off we are for my money. Someone offering money? Quick, who's got the donations hat... :-) Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Man pages for review
Wes Peters wrote: > > I have written man pages for aio_write, aio_error, aio_return, > aio_cancel, aio_suspend, and lio_listio. They are in my ~ on > freefall if anyone would like to review them. I have also edited > aio_read.2 and aio.h to correct minor problems, if you would like > to review those as well. While I cannot review them, I wish to nominate you for Hero of the Week. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
interesting bug in /usr/bin/cmp
If someone is interested to solve a problem: $ dd if=/dev/zero bs=8848 count=1 of=a 2>/dev/null $ cp a b $ cmp a b 0 0x300 Segmentation fault (core dumped) $ cmp a b 0 0x200 cmp: EOF on b $ cmp a b 0x300 0 cmp: EOF on a Jean-Marc -- Jean-Marc ZucconiPGP Key: finger j...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
userfs help needed.
I am wading through the portalfs and nullfs source, but I am desperately lost. I would love to be able to find out who would be willing to help out with questions. I feel I would be spamming far too many people by just sending to -hackers. Some of the topics I am curious about are general fs-style questions, what the various vop/vfs calls do. Also I would like to know how to setup a shared memory segment between kernel and user space (as matt dillon suggested). Finally I would like to know how the buffer-cache interacts with the filesystem layer. Thanks -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Thu, Jul 29, 1999 at 01:59:45AM +0900, Daniel C. Sobral wrote: > > Sorry, but a simplistic analysis like that just won't cut for grep. > The algorithmic complexity is highly relevant here. Try this: Algorithmic complexity!?! It's a freaking grep application. There is no freaking algorithmic complexity. At least not outside of our regex library, anyways. The test you suggested doesn't show anything about that algorithmic complexity, though. If we have a slow regex library, though, I would consider that a separate problem from a slow grep. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: interesting bug in /usr/bin/cmp
> > If someone is interested to solve a problem: > > $ dd if=/dev/zero bs=8848 count=1 of=a 2>/dev/null > $ cp a b > $ cmp a b 0 0x300 > Segmentation fault (core dumped) > $ cmp a b 0 0x200 > cmp: EOF on b > $ cmp a b 0x300 0 > cmp: EOF on a > > Jean-Marc > I've seen a similar problem when doing cmp with CD-ROM devices (I believe I entered a PR on it.) I think the problem has to do with cmp's use of mmap(), and potential issues there... But, that's just a guess on my part. What makes me think so is that cmp would declare the files on a CDROM and the files on a disk drive were different, (well, it would dump core as in your example) - while cat'ing the file from the CDROM to a temp place on the same disk and doing the cmp there would indicate there are no differences The speculation was that there was some problem with the SCSI CDROM... but... - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, Jul 28, 1999 at 02:42:35PM -0600, Nate Williams wrote: > > The code is *NO* more readable by you re-ordering lines and changes > whitespace. It's white! No, dammit, it's beige! Fuck you, I said it's white! Beige! White! I dunno, I guess for some people the distinction's actually meaningful, but for myself, I was never good with colours. Colours and such aside, I will have to explain the word "politic" to Brian, someday, though. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: userfs help needed.
:I am wading through the portalfs and nullfs source, but I am desperately :lost. I would love to be able to find out who would be willing to help out :with questions. I feel I would be spamming far too many people by just sending :to -hackers. Some of the topics I am curious about are general fs-style :questions, what the various vop/vfs calls do. Also I would like to know how :to setup a shared memory segment between kernel and user space (as matt :dillon suggested). Finally I would like to know how the buffer-cache interacts :with the filesystem layer. : :Thanks :-- :David Cross | email: cro...@cs.rpi.edu :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Ouch. I don't think anyone understands the VOP stuff completely. It's a big mess -- which is why it's going to be rewritten later this year. Your best bet is to study the implementation of the UFS/FFS filesystem. It may also help to study a more recent filesystem such as coda. Specifically, ufs/ufs/ufs_vfsops.c ufs/ufs/ufs_vnops.c ufs/ffs/ffs_vfsops.c ufs/ffs/ffs_vnops.c coda/coda_vfsops.c coda/coda_vnops.c What I recommend is that you implement a skeleton that essentially returns an error for all the call entries and does a kernel printf(), and then implement the routines one at a time. The various VOP calls have different locking requirements and resource freeing requirements. The most difficult resource to deal with in the entire subsystem is the struct componentname structure used for lookup and related ops - all related to namei. That is, the code that deals with path elements. Generally speaking the VOP code is required to free a pathname component before returning, but not in all cases. It's a really odd set of rules and I'd have to review them myself to be able to explain them. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, Jul 28, 1999 at 02:40:19PM -0600, Nate Williams wrote: > > Or is this Linux, where we don't give a rip and whatever the current > patch does to the rest of the tree is fine, since the more code we have > the better? Nate, you know damn well that's not true. You're complaining about three lines in a large patch. Further, those three lines of the patch fix excessively long (+80 char) lines. Yes, you're right that those are non-functional changes and that ideally non-functional changes are placed in separate commits. You've also been around long enough to know that you're right and to be able to say so with an air of authority without a sense of insecurity, ending any debate about it after a mere 2 or 3 curt exchanges. Further, your communication skills should be sufficiently advanced to have noticed what appears (to me, at least) to have been the subtle miscommunication that occurred between message-id <199907282000.oaa02...@mt.sri.com> and message-id which lead to the stupid place you two are now sitting in. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
:> The code is *NO* more readable by you re-ordering lines and changes :> whitespace. :... : :. Sounds like one of many arguments I've had with various people who insist on nitpicking and critiqing to death tiny little itsy bitsy inconsistancies that no normal person would care about, in a commit that may have taken the author hours of work to make happen. Gee, someone getting a little hot under the collar? Why am I not surprised. It's one thing when the style's clash badly, quite another when the differences are minor -- things like blank lines (or lack of). I'll tell you something, folks, we don't need that kind of aggravation when the style differences are minor. If people want to insist on nitpicking the code, I recommend a rules change: Such people have to wait a month first, and then offer to make the style fix FOR the author rather then badger the author of the patch to do it. After all, the author of the patch is simply trying to fix the code, and spending a considerable amount of his own time doing so. The nitpicker, on the otherhand, is acting like a spoiled brat who can't be bothered to make the change himself after asking for (and almost certainly getting) permission. After a month, when the code in question is less likely to be under active development and the patch won't mess up the developers own tracking of the work, the nitpicker can offer to make the style commit. That strikes me as being quite fair. I also take exception to people trying to use KNF as a defense for their nitpicking. KNF is all well and fine, but it is not possible to lock any style in stone for years and years. You don't get new blood into a project that way, and only the few originals left in the crew wind up being comfortable with it. For example, take the evolution of procedural prototypes. When procedures were initially prototyped a lot of work went into the __P() style to allow compilation with and without prototypes. But in the last few years a significant portion of the code no longer bothers with __P() --- because the code is *expected* to be prototyped and *expected* to be compiled with a compiler that understands them. I am sick and tired of standards which are unable to evolve with the times and I am sick and tired of people who try to enforce standards yet are unwilling to allow them to evolve in any meaningful fashion. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: userfs help needed.
On Wed, 28 Jul 1999, Matthew Dillon wrote: > Ouch. I don't think anyone understands the VOP stuff completely. It's > a big mess -- which is why it's going to be rewritten later this year. > > Your best bet is to study the implementation of the UFS/FFS filesystem. well, i'd do v9fs before studying ufs. I tried studying ufs, but I think v9fs is easier. ron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: userfs help needed.
On Wed, 28 Jul 1999, David E. Cross wrote: > I am wading through the portalfs and nullfs source, but I am desperately > lost. I would love to be able to find out who would be willing to help out > with questions. I feel I would be spamming far too many people by just > sending > to -hackers. Might I suggest the freebsd-fs mailing list? I'll be reading this thread with great interest :-) Kris To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Linear buffers in VESA screen modes
On 28 Jul 1999, Dag-Erling Smorgrav wrote: > Andrew Gordon 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? :) Sure. It's rather crude at present, but I've put it up at: http://www.arg1.demon.co.uk/vesatv.c To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
:On Wed, 28 Jul 1999, Nate Williams wrote: :> > :> > These were changes that were necessary to make ipfw readable enough that :> > I could work with it in this area. They aren't just to clean it up, or :> > just for change's sake. They need to stay in. :> :> C'mon now, re-ording the lines is *certainly* not necessary to work. : :That's true. I sure didn't do that. : :> :> *rant on* :> Brian, FreeBSD isn't your private playground for playing around, this is :> a group project, and you gotta follow the rules, or you don't get to :> play with the rest of the folks : :The rules don't say "leave the code that you work with in a bigger mess than :when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be :done to get work done, very often. You have to learn to deal with that. : :> *rant off* :> :> Nate :> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ : gr...@freebsd.org _ __ ___ | _ ) __| \ Side note: I do the same thing: clean up certain portions of the code in order to make them more readable while I'm working on the module. And while I tend to agree that it would be nice to commit the bug fixes separately, it just isn't practical most of the time because one might have already spent too big a chunk of one's own time to do the work in the first place. And I get the same sort of crap from certain core members, too. It's truely annoying when you've spent the time ( sometimes a whole LOT of time ) and trouble to fix something and all some people can do is complain about extremely trivial elements of the work. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On 26 Jul 1999, Dag-Erling Smorgrav wrote: > Sheldon Hearn writes: > > I plan to mention in the comments for each service in /etc/services, the > > latest RFC describing the service. > > Good idea. H... I'm not sure what this gets us. Wouldn't it be better to place this kind of information in the man page that you suggest below? As often as /etc/services gets read, do we really want to bloat it with non-functional information? > Don't. Instead, put it in a separate rfc(7) man page which you refer > to in the services(5) man page. Good suggestions all the way around. I'd also like to throw in this link, which is the best RFC repository I've seen on the basis of speed, reliability, and cross-indexing: http://www.cis.ohio-state.edu/hypertext/information/rfc.html. If you really want to improve /etc/services, the first commit should be to delete all the extraneous whitespace at the end of the lines. 23$ grep -c ' $' /etc/services 173 25$ grep -c '^I$' /etc/services 97 Next it would be nice if we added entries for things in our system that don't have them. (Hint: what's listening on ports 1022 and 1023?) Then, someone either needs to fix getserv*() so that they accept port ranges like 6000-6063/tcp (much preferred) or roll out those port numbers in /etc/services (yuck). It would also be nice if someone would take another look at bringing our /etc/services file more up to date with IANA (http://www.isi.edu/in-notes/iana/assignments/port-numbers). I believe someone has a PR open on this... :) David O'Brien and I were working on it for a while, but we both got busy working on other things. I had a pretty good set of scripts going to produce a workable file in services format from the IANA list, but what I should really do is write one perl script to do it. I fear however that the chance of the file being updated on that kind of scale would be very small (it always meets a lot of resistance) so I'm not sure it would be worth it. Ideas? Comments? Finally I want to urge a lot of caution to anyone who tampers with the file. I learned from painful experience that very small errors can lead to big problems in very unexpected ways. For instance, my ipfw firewall went totally nutso at one point because I had some comments in /etc/services in the wrong format back when I was playing around with it. This is not something to be tampered with lightly. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
:> Sheldon Hearn writes: :> > I plan to mention in the comments for each service in /etc/services, the :> > latest RFC describing the service. :> :> Good idea. : : H... I'm not sure what this gets us. Wouldn't it be better to :place this kind of information in the man page that you suggest below? As :often as /etc/services gets read, do we really want to bloat it with :non-functional information? :... :Doug I kinda like the idea of putting the RFC numbers in comments in /etc/services. It makes the comments more meaningful. : If you really want to improve /etc/services, the first commit :should be to delete all the extraneous whitespace at the end of the lines. : :23$ grep -c ' $' /etc/services :173 : :25$ grep -c '^I$' /etc/services :97 :... It would be nice if we DBM'd /etc/services. /etc/services is 61KB+ now, I think DBMing it in a manner similar to how some of the other system files which are DBM'd would be worthwhile. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Linear buffers in VESA screen modes
On 29-Jul-99 Andrew Gordon wrote: > On 28 Jul 1999, Dag-Erling Smorgrav wrote: > >> Andrew Gordon 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? :) > > Sure. It's rather crude at present, but I've put it up at: > > http://www.arg1.demon.co.uk/vesatv.c My wincast tv card seemed to work w/o your patch to vesa.c. Although I don't think it set the resolution right. I need to get to somewhere that I can get to more than just static though. :) Once I do, I may try and add some support for changing channels and what not, if you don't mind. --- John Baldwin -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Was someone looking for a BSD licensed stat(1)?
According to Keith Stevenson: > Sure, I can work on that. It would be helpful if you could include a few > sample outputs that I could work from. You may also want to look at the builtin stat(1) function in zsh too. 3.1.5+ only, I don't think 3.1.4 had it. BTW 3.1.6 now pretty close to release. stat [ -gnNlLtTrs ] [ -f fd ] [ -H hash ] [ -A array ] [ -F fmt ] [ +element ] [ file ... ] The command acts as a front end to the stat system call (see stat(2)). If the stat call fails, the appropriate system error message printed and status 1 is returned. The fields of struct stat give information about the files provided as arguments to the command. In addition to those available from the stat call, an extra element `link' is pro- vided. These elements are: device The number of the device on which the file resides. inode The unique number of the file on this device (`inode' number). mode The mode of the file; that is, the file's type and access permissions. With the -s option, this will be returned as a string corresponding to the first column in the display of the ls -l command. nlink The number of hard links to the file. uidThe user ID of the owner of the file. With the -s option, this is displayed as a user name. gidThe group ID of the file. With the -s option, this is displayed as a group name. rdev The raw device number. This is only useful for special devices. size The size of the file in bytes. atime mtime ctime The last access, modification and inode change times of the file, respectively, as the number of seconds since midnight GMT on 1st January, 1970. With the -s option, these are printed as strings for the local time zone; the format can be altered with the -F option, and with the -g option the times are in GMT. blksize The number of bytes in one allocation block on the device on which the file resides. block The number of disk blocks used by the file. link If the file is a link and the -L option is in effect, this contains the name of the file linked to, otherwise it is empty. Note that if this element is selected (``stat +link'') then the -L option is automatically used. A particular element may be selected by including its name preceded by a `+' in the option list; only one element is allowed. The element may be short- ened to any unique set of leading characters. Oth- erwise, all elements will be shown for all files. Options: -A array Instead of displaying the results on stan- dard output, assign them to an array, one struct stat element per array element for each file in order. In this case neither the name of the element nor the name of the files is provided unless the -t or -n options are provided, respectively. In the former case the element name appears as a prefix to the appropriate array element and in the latter case the file name appears as a separate array element preceding all the others. Other formatting options are respected. -H hash Similar to -A, but instead assign the values to hash. The keys are the elements listed above. If the -n option is provided then the name of the file is included in the hash with key name. -f fd Use the file on file descriptor fd instead of named files; no list of file names is allowed in this case. -F fmt Supplies a strftime (see strftime(3)) string for the formatting of the time elements. The -s option is implied. -g Show the time elements in the GM
Re: Replace/rewrite reverse.c for tail(1)
Because of licensing restrictions in our product, we are unable to ship with any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I saw tac, and agree that it is faster for this specific use) Any VM people wanna pipe up and make a suggestion so that I may make up a patch? Kevin [Charset iso-8859-1 unsupported, filtering to ASCII...] > I'd suggest that you use "tac" from GNU textutils. > > Charles > > -Original Message- > From: Kevin Day [mailto:toa...@dragondata.com] > Sent: Wednesday, July 28, 1999 3:09 AM > To: hack...@freebsd.org > Subject: Replace/rewrite reverse.c for tail(1) > > An application I use quite often requires me to reverse the lines in the > file to get the desired output. > > 'tail -r' appears to be very inefficient in it's use of mmap(). It mmap's > the entire file in, which encourages the kernel to swap out the rest of the > system to keep pages of the input file in memory. > > 58350 root 54 0 412M 85244K RUN 0:14 19.78% 19.19% tail > > Out of 128M of ram, it's swapped nearly everything else out to keep 85M of > this 400M file in ram, even though it will never touch it again. :) > > I see two possible fixes for this. One could be madvise'ing periodically > with MADV_DONTNEED. If I understand correctly, this would help a bit, right? > > Or, mmap smaller regions of the file, and keep moving the buffer. This would > also help with files exceeding mmap's limits. > > > Any thoughts? > > > Kevin > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replace/rewrite reverse.c for tail(1)
:Because of licensing restrictions in our product, we are unable to ship with :any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I :saw tac, and agree that it is faster for this specific use) : :Any VM people wanna pipe up and make a suggestion so that I may make up a :patch? : :Kevin I don't think madvise()ing it MADV_DONTNEED will work right now. The madvise() calls only work with OBJT_DEFAULT and OBJT_SWAP objects -- i.e. swap-backed memory. They will not do anything to pages owned by file mmaps. We could fix vm/vm_object.c/vm_object_madvise() to handle MADV_DONTNEED for other objects. It would not be too difficult to do, actually, since we would be doing nothing more then moving the (must be clean) page to VM cache to get it to be reused more quickly. This is a fix I could make to CURRENT without too much trouble. -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replace/rewrite reverse.c for tail(1)
> > :Because of licensing restrictions in our product, we are unable to ship with > :any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I > :saw tac, and agree that it is faster for this specific use) > : > :Any VM people wanna pipe up and make a suggestion so that I may make up a > :patch? > : > :Kevin > > I don't think madvise()ing it MADV_DONTNEED will work right now. The > madvise() calls only work with OBJT_DEFAULT and OBJT_SWAP objects -- i.e. > swap-backed memory. They will not do anything to pages owned by > file mmaps. > > We could fix vm/vm_object.c/vm_object_madvise() to handle > MADV_DONTNEED for other objects. It would not be too difficult to > do, actually, since we would be doing nothing more then moving the > (must be clean) page to VM cache to get it to be reused more quickly. > This is a fix I could make to CURRENT without too much trouble. > > -Matt > Wow, that's interesting. While I never looked at the code, I *thought* I was able to measure a speed boost in a certain large embedded application I'm working on, with adding some madvise()'s in to mmap'ed files. (Streaming video madvise'ed with MADV_SEQUENTIAL seemed to be slightly faster, but it may have been insignificant) This is a problem I've run into a few times before, actually. One-time use data that will shove the entire system out of ram, and no convenient way to tell the kernel that it shouldn't bother holding on to it. I believe dg ran into this too, and had some fix he was using on ftp.cdrom.com. In my application, when I play a movie, it'd be nice to be able to specify a priority. "Try to keep this, even if it means possibly swapping" (current behavior) or "Don't swap out anything for this object, it's far too large to bother with trying to hold on to it and/or it will only be used once." Granted 'large' is one of those fuzzy terms, but when you do know that the 900M file you're reading is being done sequentially from start to finish, swapping things out to try to keep more of it in swap is probably bad. :) Kevin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replace/rewrite reverse.c for tail(1)
:Wow, that's interesting. While I never looked at the code, I *thought* I was :able to measure a speed boost in a certain large embedded application I'm :working on, with adding some madvise()'s in to mmap'ed files. (Streaming :video madvise'ed with MADV_SEQUENTIAL seemed to be slightly faster, but it :may have been insignificant) MADV_SEQUENTIAL *WILL* work. It changes the page fault read-behind/read-ahead. Normally the VM system reads behind a bit as well as reads ahead. If you set MADV_SEQUENTIAL it shifts to just doing read-ahead, and it does more of it. The madvise() types that just flag the VM object work on any type of object. The madvise() types that actually mess with VM pages currently only work on swap-backed pages. MADV_WILLNEED scans for VM pages in object MADV_DONTNEED scans for VM pages in object MADV_FREE scans for VM pages in object MADV_SEQUENTIAL just flags the object MADV_RANDOM just flags the object MADV_NORMAL just flags the object :Granted 'large' is one of those fuzzy terms, but when you do know that the :900M file you're reading is being done sequentially from start to finish, :swapping things out to try to keep more of it in swap is probably bad. :) : :Kevin I agree completely. When you run through the filesystem these pages will be reused more quickly. When you run through the VM system these pages are considered to be more 'active'. I think it makes sense to have madvise() MADV_WILLNEED and MADV_DONTNEED operate on file mmaps. There is a slight security concern with MADV_DONTNEED (i.e. if you loop running it on a system file that is used a lot, like /etc/group), but after thinking about it a bit I do not think it is a big deal. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: interesting bug in /usr/bin/cmp
On Wed, 28 Jul 1999, Thomas David Rivers wrote:
> >
> > If someone is interested to solve a problem:
> >
> > $ dd if=/dev/zero bs=8848 count=1 of=a 2>/dev/null
> > $ cp a b
> > $ cmp a b 0 0x300
> > Segmentation fault (core dumped)
> > $ cmp a b 0 0x200
> > cmp: EOF on b
> > $ cmp a b 0x300 0
> > cmp: EOF on a
> >
> > Jean-Marc
> >
>
> I've seen a similar problem when doing cmp with CD-ROM
> devices (I believe I entered a PR on it.)
>
> I think the problem has to do with cmp's use of mmap(), and
> potential issues there... But, that's just a guess on my part.
It has to do with mmap(), but not any specific issues with mmap(), just a
bug in its use.
If noone has any objections, I will commit this and MFC it in a week or so.
--- src/usr.bin/cmp/regular.c.orig Thu Jul 29 00:43:50 1999
+++ src/usr.bin/cmp/regular.c Thu Jul 29 00:44:54 1999
@@ -57,7 +57,7 @@
off_t skip1, len1, skip2, len2;
{
u_char ch, *p1, *p2;
- off_t byte, length, line;
+ off_t byte, length, line, mlength;
int dfound;
off_t pagemask, off1, off2;
@@ -76,17 +76,18 @@
off2 = ROUNDPAGE(skip2);
length = MIN(len1, len2);
- if (length > SIZE_T_MAX)
+ mlength = MAX(len1, len2);
+ if (mlength > SIZE_T_MAX)
return (c_special(fd1, file1, skip1, fd2, file2, skip2));
if ((p1 = (u_char *)mmap(NULL,
- (size_t)length, PROT_READ, MAP_SHARED, fd1, off1)) == (u_char
*)MAP_FAILED)
+ (size_t)mlength, PROT_READ, MAP_SHARED, fd1, off1)) == (u_char
*)MAP_FAILED)
err(ERR_EXIT, "%s", file1);
- madvise(p1, length, MADV_SEQUENTIAL);
+ madvise(p1, mlength, MADV_SEQUENTIAL);
if ((p2 = (u_char *)mmap(NULL,
- (size_t)length, PROT_READ, MAP_SHARED, fd2, off2)) == (u_char
*)MAP_FAILED)
+ (size_t)mlength, PROT_READ, MAP_SHARED, fd2, off2)) == (u_char
*)MAP_FAILED)
err(ERR_EXIT, "%s", file2);
- madvise(p2, length, MADV_SEQUENTIAL);
+ madvise(p2, mlength, MADV_SEQUENTIAL);
dfound = 0;
p1 += skip1 - off1;
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
/usr/share/man/man?/{i386|alpha}
Hello !
I am interesting about idea of directories man?/{i386|alpha}.
By their names I can understand that they are directories there
platform specific man pages for certain man section will be stored.
As I see there are only hard-linked manpages in man?/i386 directories. But
it's interesting -- will these directories be used in future for
storing unique (not hard-linked with other man pages) man pages ?
If so, then I can add some patches for makewhatis(1)/catman(1) while
I am working with internationalization support for this stuff.
PS: Yes, these utilities not contain functionality to understand
subdirectories in man directories.
--
Sincerely Yours, | [EMAIL PROTECTED] (primary)
Alexey Zelkin | [EMAIL PROTECTED] (home)
| ICQ: #6196584, FIDO: 2:460/12.26
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Tue, 27 Jul 1999 22:20:40 MST, "David O'Brien" wrote: > My advice would be to submit his PR to Chris Demtrito(sp?), file's > maintainer. Then import NetBSD's file (Chris is a NetBSD guy). Hmmm. So file(1) is a contrib candidate? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Replace/rewrite reverse.c for tail(1)
An application I use quite often requires me to reverse the lines in the file to get the desired output. 'tail -r' appears to be very inefficient in it's use of mmap(). It mmap's the entire file in, which encourages the kernel to swap out the rest of the system to keep pages of the input file in memory. 58350 root 54 0 412M 85244K RUN 0:14 19.78% 19.19% tail Out of 128M of ram, it's swapped nearly everything else out to keep 85M of this 400M file in ram, even though it will never touch it again. :) I see two possible fixes for this. One could be madvise'ing periodically with MADV_DONTNEED. If I understand correctly, this would help a bit, right? Or, mmap smaller regions of the file, and keep moving the buffer. This would also help with files exceeding mmap's limits. Any thoughts? Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Tue, 27 Jul 1999 22:20:40 MST, "David O'Brien" wrote: > > My advice would be to submit his PR to Chris Demtrito(sp?), file's > > maintainer. Then import NetBSD's file (Chris is a NetBSD guy). You may want to verify this. I'm pretty sure that Christos Zoulas (another NetBSD guy) maintains file(1): [EMAIL PROTECTED] - ad To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Wed, 28 Jul 1999 12:03:25 +0100, Andy Doran wrote: > You may want to verify this. I'm pretty sure that Christos Zoulas > (another NetBSD guy) maintains file(1): [EMAIL PROTECTED] Confirmed. Other than the mistaken name, I think David obsoleted further discussion, since it really is the best approach. :-) Thanks, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
newaliases and 256 tun devices
Hi ...
I previously mailed the same error ... and then I thought
it was a "miss-corrolation" between kernel sources and
userland. Since then I built a SNAP of 990726 sources
and tried the same thing and the error occured again .
Same sources used for the compile of the kernel and userlevel
binaries.
I've now traced the following down ... it has something todo
with the changes in net/if_dl.h (the entries added for
source routing and the fact that my kernel has
pseudo-device tun 255
in the config.
Setup.
PII400 / Asus P2-99 990726 SNAP / fxp and de0 cards.
When I do a "ifconfig fxp0 delete" and then a newaliases
the newaliases exits with a segmentation failt.
If I reconfig the device or up the device ... newaliases works
ok.
I then built a kernel with only 200 tun devices. Then newaliases
works everytime. It seems that gated also suffers from the same
problem in that if no device is configured it exits on signal 6
(core dumped)
Just for reference this works fine on a 2.2.7/8 FreeBSD without
any problems ...
The problem seems to be in conf.c of sendmail round line 4429
if there is 255 tun devices the for loop below only gets to
234 +/- and then doesn't check anything further and crashes
(but only if the working interface is deleted)
gdb shows that the pointer *sa points to somewhere wonderful :)
It must have something todo with the moving of this pointer
through the list ???
Was anything changed for the amount of tun devices allowed ??
for (i = 0; i < ifc.ifc_len; )
{
struct ifreq *ifr = (struct ifreq *) &ifc.ifc_buf[i];
SOCKADDR *sa = (SOCKADDR *) &ifr->ifr_addr;
struct in_addr ia;
#ifdef SIOCGIFFLAGS
struct ifreq ifrf;
#endif
char ip_addr[256];
extern char *inet_ntoa();
#ifdef BSD4_4_SOCKADDR
if (sa->sa.sa_len > sizeof ifr->ifr_addr)
i += sizeof ifr->ifr_name + sa->sa.sa_len;
else
#endif
i += sizeof *ifr;
if (tTd(0, 20))
printf("%s\n", anynet_ntoa(sa));
Thanx
Reinier
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: replacing grep(1)
On Wed, Jul 28, 1999 at 03:30:58AM -0400, Dag-Erling Smorgrav wrote: > > > There seems to be at least one dependency on GNU grep in > > /ports/Mk/bsd.port.mk where the -F argument is used. > > -F is implemented. I saw that, but had assumed the semantics were different. I should have read the read the manpages more closely: they're not. Sorry. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
/usr/src/sys/i386/boot/netboot problem during compile
I have a problem compiling of files needed for network boot on a FreeBSD 3.2-Release. As it was writen in handbook, I have to compile nb8390.com, nb3c509.com, nb8390.rom, nb3c509.rom files to perform boot over network. But during compile a I get the following error: /usr/src/sys/i386/boot/netboot > make Warning: Object directory not changed from original /usr/src/sys/i386/boot/netboot ln -s /usr/src/sys/i386/boot/netboot/../../include /usr/src/sys/i386/boot/netboot/machine cc -O2 -DNFS -DROMSIZE=16384 -DRELOC=0x9 -DPCI -DPCI_VENDOR=0x10ec -DPCI_DEVICE=0x8029 -DPCI_CLASS=0x02,0x00,0x00 -DASK_BOOT -aout -I/usr/src/sys/i386/boot/ netboot/../../.. -I/usr/src/sys/i386/boot/netboot -DROMSIZE=16384 -static -o makerom /usr/src/sys/i386/boot/netboot/makerom.c ld: scrt0.o: No such file or directory *** Error code 1 as I understand I need this file (scrt0.o) because netboot makes *com files only from a.out files, not from ELF. In sources I found where is this file compiled - /usr/src/lib/csu. But it will only compile if I manually set flag FREEBSD_AOUT. And even after this, compiling netboot gives me: ld: /usr/lib/scrt0.o: malformed input file (not rel or archive) *** Error code 1 Please write me what I am doing wrong, and how can I get this *.com and *.rom files neede for network boot? 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: /usr/src/sys/i386/boot/netboot problem during compile
Dima wrote: > I have a problem compiling of files needed for network boot on a FreeBSD > 3.2-Release. > as I understand I need this file (scrt0.o) because netboot makes *com > files only from a.out files, not from ELF. In sources I found where is > this file compiled - /usr/src/lib/csu. But it will only compile if I > manually set flag FREEBSD_AOUT. And even after this, compiling netboot > gives me: > ld: /usr/lib/scrt0.o: malformed input file (not rel or archive) > *** Error code 1 > > Please write me what I am doing wrong, and how can I get this *.com and > *.rom files neede for network boot? This is legacy code which is being kept around until loader(8) supports equivalent functionality. For now, I suggest you use "etherboot" in the ports collection. -- Robert Nordier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
POSIX threads question
HI everybody. I'm having a problem writing a multi-threaded application. As I understand from the mans, calls to read and write are synchronized through file-locks. Having looked through the source for libc_r I noticed that calls to printf and fprintf are also synchronized. The question is - why I am still having a problem calling fprintf(stderr, ... from multiple threads, the output is simply not written until I make a socond or a third call to fprintf. I have disabled buffering for stderr with setvbuf. Thank you in advance. --- Sent by InfoArt iMail http://www.infoart.ru; http://www.stars.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, 28 Jul 1999, Brian F. Feldman wrote: > > > If it will get ALL of you to give it a rest, how about: > > > per-rule logging limits > > > logging limit raising > > > logging limit resetting > > > Which would all NOT affect the statistics? Separate statistics/logging counters is fine, but i don't need per-rule limits, a global limit is ok --> sysctl -w for raising and ipfw zerolog (or reset) for resetting. And then ... securelevel == 3 I think it is better NOT to permit 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile faster to avoid DoS > > > > We need more input from people who use the code, to make sure they don't > > depend on the current 'features', or can live with changes to them. If you can keep the foot print small i can live with it. > > > > Implementing it is the easy part, making sure it's the right thing to do > > is the hard part. Right! > > Well, the easy part is done, except for raising limits. Look: > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > ipfw: Entry 1 logging count reset. > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > > I think this feature should DEFINITELY go in. I'm going to clean it up some > (ip_fw.c itself), and then make a set of diffs for this feature. > Nice? :) Nice? Depends on the diffs AND the man page ;-) Henk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: newaliases and 256 tun devices
If it's of any use, I have 300 tun devices in my home development
machine and have no problems with sendmail, but I have a tulip card
(de) rather than an Intel and haven't every ``ifconfig delete''d it.
> Hi ...
>
>
> I previously mailed the same error ... and then I thought
> it was a "miss-corrolation" between kernel sources and
> userland. Since then I built a SNAP of 990726 sources
> and tried the same thing and the error occured again .
>
> Same sources used for the compile of the kernel and userlevel
> binaries.
>
> I've now traced the following down ... it has something todo
> with the changes in net/if_dl.h (the entries added for
> source routing and the fact that my kernel has
> pseudo-device tun 255
> in the config.
>
> Setup.
> PII400 / Asus P2-99 990726 SNAP / fxp and de0 cards.
>
> When I do a "ifconfig fxp0 delete" and then a newaliases
> the newaliases exits with a segmentation failt.
> If I reconfig the device or up the device ... newaliases works
> ok.
>
> I then built a kernel with only 200 tun devices. Then newaliases
> works everytime. It seems that gated also suffers from the same
> problem in that if no device is configured it exits on signal 6
> (core dumped)
>
> Just for reference this works fine on a 2.2.7/8 FreeBSD without
> any problems ...
>
> The problem seems to be in conf.c of sendmail round line 4429
> if there is 255 tun devices the for loop below only gets to
> 234 +/- and then doesn't check anything further and crashes
> (but only if the working interface is deleted)
> gdb shows that the pointer *sa points to somewhere wonderful :)
> It must have something todo with the moving of this pointer
> through the list ???
>
> Was anything changed for the amount of tun devices allowed ??
>
> for (i = 0; i < ifc.ifc_len; )
> {
> struct ifreq *ifr = (struct ifreq *) &ifc.ifc_buf[i];
> SOCKADDR *sa = (SOCKADDR *) &ifr->ifr_addr;
> struct in_addr ia;
> #ifdef SIOCGIFFLAGS
> struct ifreq ifrf;
> #endif
> char ip_addr[256];
> extern char *inet_ntoa();
>
> #ifdef BSD4_4_SOCKADDR
> if (sa->sa.sa_len > sizeof ifr->ifr_addr)
> i += sizeof ifr->ifr_name + sa->sa.sa_len;
> else
> #endif
> i += sizeof *ifr;
>
> if (tTd(0, 20))
> printf("%s\n", anynet_ntoa(sa));
>
>
>
> Thanx
> Reinier
--
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour ! <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Tue, 27 Jul 1999, Julian Elischer wrote: > a system wide limit and each rule's logging counter individually resetable > back to 0. > > So, what's your vote? > > ... Joe I vote for this too. Henk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Replace/rewrite reverse.c for tail(1)
I'd suggest that you use "tac" from GNU textutils. Charles -Original Message- From: Kevin Day [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 28, 1999 3:09 AM To: [EMAIL PROTECTED] Subject: Replace/rewrite reverse.c for tail(1) An application I use quite often requires me to reverse the lines in the file to get the desired output. 'tail -r' appears to be very inefficient in it's use of mmap(). It mmap's the entire file in, which encourages the kernel to swap out the rest of the system to keep pages of the input file in memory. 58350 root 54 0 412M 85244K RUN 0:14 19.78% 19.19% tail Out of 128M of ram, it's swapped nearly everything else out to keep 85M of this 400M file in ram, even though it will never touch it again. :) I see two possible fixes for this. One could be madvise'ing periodically with MADV_DONTNEED. If I understand correctly, this would help a bit, right? Or, mmap smaller regions of the file, and keep moving the buffer. This would also help with files exceeding mmap's limits. Any thoughts? Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pasting data between terminals
Krzysztof Krawczyk wrote: > When I do: > echo "blah blah" >>/dev/ttyp1 > text "blah blah" appear in virtual terminal ttyp1, but only as a text of > "message". I need ttyp1 count those datas as a "command typed by hand", > not just a text displayed in this term as info. I must transport lots of > data between these terminals. Have you any ideas? have you tried using a pseudo-terminal? see pty(4) -- Tom Uffner [EMAIL PROTECTED] Themes were useless! Destiny was here and the foot pedals were bleeding! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> And then ... securelevel == 3 I think it is better NOT to permit > 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile > faster to avoid DoS The real issue we are dealing with is what happens at securelevel == 3. What you are saying is that people shouldn't be allowed to modify *anything* at securelevel == 3, correct? Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > Implementing it is the easy part, making sure it's the right thing to do > > is the hard part. > > Well, the easy part is done, except for raising limits. Look: > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > ipfw: Entry 1 logging count reset. > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > > Nice? :) Depends on how it effects the speed of the system and if it makes the code too complex. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
In message <[EMAIL PROTECTED]> "David O'Brien" writes: : Before importing, it must display a version number of 1.0 (or drop the : version number). This is not Linux where everything is version 0.xy. For a long time the new boot loader was in the tree with a version 0.xx... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/12852: Non-standard behavior of fread(3)
Hi folks, Could someone have a look at the patch proposed on PR 12852? I understand the motivation, since it seems reasonable to me that ferror() should return EBADF after an attempt to read from stdout. At the moment, ferror() returns 0 after an attempt to read from stdout. Thanks, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
> > > My advice would be to submit his PR to Chris Demtrito(sp?), file's > > You may want to verify this. I'm pretty sure that Christos Zoulas > (another NetBSD guy) maintains file(1): [EMAIL PROTECTED] My major Duh!! If Christos sees this thread, my apologies. There is no excuse for me not checking the source to make sure I was accurate before opening my mouth. -- -- David([EMAIL PROTECTED] -or- [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 wrote: > > Due to the discussion of speed, I have been looking at it and it is really > slow. Even slower than I thought and I was thinking it was pretty slow. > > So using gprof, I have discovered that it seems to spend a whole mess of > time in grep_malloc() and free(). So I pulled all the references to > malloc inside the main loop (the copy for ln.dat and removed queueing). > This stills leaves us with a grep that is about ~6x slower than GNU. > Before that, it ran closer to 80x. After this, gprof says it spends > around 53% of its time in procline(). Sorry, but a simplistic analysis like that just won't cut for grep. The algorithmic complexity is highly relevant here. Try this: generate a 1 Mb file, and then generate 10 Mb and 50 Mb files by concatenating that first file. Benchmark yours and GNU grep a number of times to get the average for each file. Now compare the *proportions* between the different sized files. Are they the same? Next, try different sized patterns on the 50 Mb file on both yours and GNU grep. Again, compare the proportion. Next, compare patterns with different number of "wildcards", patterns with things like [acegikmoqsuvxz] vs [acegikmoqsuvxzACEGIKMOQSUVXZ], etc. Either that, or do a complexity analysis of the algorithms. :-) (In case anyone reading this discussion wants to know more about complexity of algorithms, I recommend Computer Algorithms, Introduction to Design and Analysis, by Sara Baase, Addison Wesley.) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
I expect that there is a very good reason why this shouldn't be done, but could it be possible to implement two different algorithms/code dependant on the size of the file being grepped? Mark Dickey [EMAIL PROTECTED] Daniel C. Sobral wrote: > James Howard wrote: > > > > Due to the discussion of speed, I have been looking at it and it is really > > slow. Even slower than I thought and I was thinking it was pretty slow. > > > > So using gprof, I have discovered that it seems to spend a whole mess of > > time in grep_malloc() and free(). So I pulled all the references to > > malloc inside the main loop (the copy for ln.dat and removed queueing). > > This stills leaves us with a grep that is about ~6x slower than GNU. > > Before that, it ran closer to 80x. After this, gprof says it spends > > around 53% of its time in procline(). > > Sorry, but a simplistic analysis like that just won't cut for grep. > The algorithmic complexity is highly relevant here. Try this: > generate a 1 Mb file, and then generate 10 Mb and 50 Mb files by > concatenating that first file. Benchmark yours and GNU grep a number > of times to get the average for each file. Now compare the > *proportions* between the different sized files. Are they the same? > > Next, try different sized patterns on the 50 Mb file on both yours > and GNU grep. Again, compare the proportion. > > Next, compare patterns with different number of "wildcards", > patterns with things like [acegikmoqsuvxz] vs > [acegikmoqsuvxzACEGIKMOQSUVXZ], etc. > > Either that, or do a complexity analysis of the algorithms. :-) > > (In case anyone reading this discussion wants to know more about > complexity of algorithms, I recommend Computer Algorithms, > Introduction to Design and Analysis, by Sara Baase, Addison Wesley.) > > -- > Daniel C. Sobral (8-DCS) > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > "Is it true that you're a millionaire's son who never worked a day > in your life?" > "Yeah, I guess so." > "Lemme tell you, son, you ain't missed a thing." > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/12852: Non-standard behavior of fread(3)
Sheldon Hearn wrote:
> Could someone have a look at the patch proposed on PR 12852? I
> understand the motivation, since it seems reasonable to me that ferror()
> should return EBADF after an attempt to read from stdout. At the moment,
> ferror() returns 0 after an attempt to read from stdout.
There's no question this needs changing. An ISO example actually
reads along the lines of:
while (!feof(fp) && !ferror(fp))
fscanf(fp, ...);
with no further provision for error-detection. Applied to stdout,
this never terminates.
The SVID wording is more definite than ISO in discussing this ("less
than nitems only if a read error or end-of-file is encountered"),
but mostly the present behavior just conflicts with sense and
practice.
--
Robert Nordier
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
