Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Noriyuki Soda
On Thu, 15 Jul 1999 11:09:01 -0700 (PDT), Matthew Dillon dil...@apollo.backplane.com said: Umm... how are you getting the reserved numbers? pstat -s on SunOS4, and swap -s on SunOS5. From Solaris man page: :-s Print summary information about total swap :

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Matthew Dillon
:pstat -s on SunOS4, and swap -s on SunOS5. From Solaris man page: : ::-s Print summary information about total swap :: space usage and availability: :: :: allocated The total amount of swap space :: (in

Re: Advice on deriving accurate time values from the kernel?

1999-07-15 Thread John Hay
If you only want to timestamp events and not generate the event, you can use microtime() or nanotime(). On a 400MHz PII non-SMP you should get 2.5 ns resolution with nanotime(). On a normal kernel with kern.timecounter.method at the default of 0, the get... versions give you time at the last tick

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Matthew Dillon
::-s Print summary information about total swap :: space usage and availability: :: :: allocated The total amount of swap space :: (in 1024-byte blocks) ::

650 MB MFS?

1999-07-15 Thread David Miller
Are there any design limits to mfs? I want to use cdrecord to write to a dozen or so CD's at once, and fear making lots of coasters if I run them all off a single on-disk file. However, a CD only holds 650 MB, so it seems like I could have the image on mfs and sleep well sans coasters. Would

Re: 650 MB MFS?

1999-07-15 Thread Matthew Dillon
: :Are there any design limits to mfs? I want to use cdrecord to write to a :dozen or so CD's at once, and fear making lots of coasters if I run them :all off a single on-disk file. However, a CD only holds 650 MB, so it :seems like I could have the image on mfs and sleep well sans coasters. :

Re: gdb instead of adb

1999-07-15 Thread Wes Peters
Mike Smith wrote: Is the reason why adb hasn't been ported to freebsd because the source is proprietary? You make no sense. If gdb should suffice for my debugging needs, how can a breakpoint be set at a particular interrupt, or even at any interrupt? The break command only seems

Re: printing

1999-07-15 Thread Dominic Mitchell
On Thu, Jul 15, 1999 at 10:44:57AM +0100, Alex Knowles wrote: I hope this is the right place to post, sorry if it's not. I'm really sorry to post what is probably a repeat question, but I've just upgraded to freebsd 3.2-release and I'm having real problems getting the kernel to see my printer

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Andrzej Bialecki
On Wed, 14 Jul 1999, John Nemeth wrote: On Jul 15, 2:40am, Daniel C. Sobral wrote: } Garance A Drosihn wrote: } At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote: } In which case the program that consumed all memory will be killed. } The program killed is +NOT+ the one demanding

Re: seg fault in mutex_queue_enq

1999-07-15 Thread Jordan K. Hubbard
I don't care one way or the other. I could leave out the wrapped poll() very easily and avoid the issue all together. This would provide -stable with everything -current has, except of course poll(). I'd prefer to add poll, though... I'm OK with adding poll(), it just seemed odd that the

Help with PCI code understanding

1999-07-15 Thread Zhihui Zhang
Can someone outline the initialization process of PCI devices in FreeBSD? I know many of the basic stuff of PCI introduced in the book PCI System Architecture. I just want to know how each driver is registered into some linker set and its probe routine gets called. In other words, I want to

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Sheldon Hearn
[Hijacked from freebsd-security] On Thu, 15 Jul 1999 17:33:29 -0400, Garance A Drosihn wrote: What I wanted to do was have estr routines, where the destination is specified as the starting point and the ending point of the area available for the string (as two parameters). The routines

Re: make fails in 3.2-RELEASE for netboot

1999-07-15 Thread Ollivier Robert
According to Gregory A. Carter: I'm assuming that might have something to do with it. The file scrt0.c This is the old a.out crt code. The one in 3.0+ is crt1.c, look into /usr/src/lib/csu/i386-elf/. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Tim Vanderhoek
On Fri, Jul 16, 1999 at 12:15:31AM +0200, Sheldon Hearn wrote: As I understand it, the goal here is to return to the caller the number of bytes copied (however you represent it), so that the caller can easily determine whether or not dst is safe for operations demanding a null-terminated

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Matthew Dillon
:Before program start: :total: 2k bytes allocated + 4792k reserved = 24792k used, 191048k available : :After malloc, before touch: :total: 18756k bytes allocated + 37500k reserved = 56256k used, 159580k available : :After malloc + touch: :total: 52804k bytes allocated + 4852k reserved =

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Jonathan Lemon
In article local.mail.freebsd-hackers/199907151825.laa11...@apollo.backplane.com you write: ::-s Print summary information about total swap :: space usage and availability: :: :: allocated The total amount of swap space ::

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread sthaug
If this is correct, then solaris is using a VMSPACE = SWAPSPACE model. FreeBSD uses a VMSPACE = SWAPSPACE + REALMEM model. AFAIK it has been stated quite explicitly by the Solaris folks that Solaris 2.x uses VMSPACE = SWAPSPACE + REALMEM. This is *different* from SunOS 4.1.x. Steinar

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Mike Smith
On Fri, Jul 16, 1999 at 12:15:31AM +0200, Sheldon Hearn wrote: As I understand it, the goal here is to return to the caller the number of bytes copied (however you represent it), so that the caller can easily determine whether or not dst is safe for operations demanding a

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Sheldon Hearn
On Thu, 15 Jul 1999 18:34:42 -0400, Tim Vanderhoek wrote: if (fooncat(string, append, sizeof(string)) != strlen(append)) ... which is rather evil, given that the second strlen(append) would be completely gratuitous if it weren't for the interface you're suggesting. Tim, you're doing

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Julian Elischer
On Thu, 15 Jul 1999, Mike Smith wrote: What's really stupid is that most of the time you're trying to use these functions to fix code that looks like: strcpy(buf, str1); strcat(buf, str2); strcat(buf, str3); without overflowing buf. This is dumb! Use asprintf

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Paul Hart
On Thu, 15 Jul 1999, Julian Elischer wrote: There was a talk on these (strlcpy(3) and strlcat(3)) at USENIX. The logic as to their design was presented and I agree totally with the way that the logic was played out into the functions. They are described in the FreeNIX proceedings on page

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Matthew Dillon
Here is what I get from one of BEST's mail www proxy machines. ~dillon/br adds the object size's together. 'swap' and 'default' objects refers to unbacked VM objects - and none of the processes running fork shared unbacked objects so we don't have to worry about that. The

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Mike Smith
What's really stupid is that most of the time you're trying to use these functions to fix code that looks like: strcpy(buf, str1); strcat(buf, str2); strcat(buf, str3); without overflowing buf. This is dumb! Use asprintf instead: There was a talk on these

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Mike Smith
On Thu, 15 Jul 1999, Julian Elischer wrote: There was a talk on these (strlcpy(3) and strlcat(3)) at USENIX. The logic as to their design was presented and I agree totally with the way that the logic was played out into the functions. They are described in the FreeNIX proceedings on

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Mike Smith
Ugh. Take the first example in the paper; it rewrites as len = asprintf(path, %s/.foorc); ^ , homedir Whoops. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Paul Hart
On Thu, 15 Jul 1999, Mike Smith wrote: Ugh. Take the first example in the paper; it rewrites as len = asprintf(path, %s/.foorc); as opposed to strlcat(path, homedir, sizeof(path)); strlcat(path, /, sizeof(path)); strlcat(path, .foord, sizeof(path)); len

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Tim Vanderhoek
On Fri, Jul 16, 1999 at 12:53:13AM +0200, Sheldon Hearn wrote: If all you're saying is that you want an API that doesn't require a test against the known length of src (append in your example), then you won't like strl*. :-) Well, if I read your message correctly, the difference between

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Garance A Drosihn
At 12:15 AM +0200 7/16/99, Sheldon Hearn wrote: [Hijacked from freebsd-security] For those who missed the original article, here's the initial topic (from Paul Hart, but truncated a bit): I was just reviewing the proceedings from the USENIX 1999 Annual Technical Conference where Todd

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread lyndon
In that scenario, the 512MB of swap I assigned to this machine would be dangerously low. With 13GB disks available for a couple of hundred bucks, my machines aren't going to run out of swap space any time soon, even if I commit to disk. All I want for Christmas is a knob to disable

Re: make fails in 3.2-RELEASE for netboot

1999-07-15 Thread Gregory A. Carter
Ollivier Robert [Re: make fails in 3.2-RELEASE for netboot] 7.16.1999 .. . According to Gregory A. Carter: . I'm assuming that might have something to do with it. The file scrt0.c . . This is the old a.out crt code. The

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Sheldon Hearn
On Thu, 15 Jul 1999 17:53:52 CST, lyn...@orthanc.ab.ca wrote: All I want for Christmas is a knob to disable overcommit. And what I'm pretty sure the majority of the readers on this list want is for those of you who really think it's necessary to do it yourselves. What? Nobody who wants to

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Mike Smith
On Thu, 15 Jul 1999, Mike Smith wrote: Ugh. Take the first example in the paper; it rewrites as len = asprintf(path, %s/.foorc); as opposed to strlcat(path, homedir, sizeof(path)); strlcat(path, /, sizeof(path)); strlcat(path, .foord, sizeof(path));

Re: Swap overcommit

1999-07-15 Thread Andrew Reilly
On Thu, Jul 15, 1999 at 11:48:41PM +0900, Daniel C. Sobral wrote: Actually, applications are written assuming that malloc() will not fail, generally speaking. Is this really the case? I'm pretty sure I've _never_ ignored the possibility of a NULL return from malloc, and I've been using it for

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Julian Elischer
but what about While ( more data items) { copy data items onto end of buffer if full{ write out buffer clear buffer, copy in rest of last item. } } I'd certainly not want to use xxprintf() for that On Thu, 15 Jul 1999, Mike Smith wrote: On Thu, 15 Jul 1999, Mike Smith

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Mike Smith
but what about While ( more data items) { copy data items onto end of buffer if full{ write out buffer clear buffer, copy in rest of last item. } } I'd certainly not want to use xxprintf() for that This is what stdio does, funnily enough. See fwrite() etc. -- \\

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Warner Losh
In message 199907152358.qaa01...@dingo.cdrom.com Mike Smith writes: : if (strlen(buf) = sizeof(buf)) : return(error); This can never be true with the strl functions They don't run off the end, so strlen(buf) is always going to be sizeof(buf) since it doesn't include the

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Warner Losh
In message 199907152244.paa01...@dingo.cdrom.com Mike Smith writes: : What's really stupid is that most of the time you're trying to use : these functions to fix code that looks like: : strcpy(buf, str1); : strcat(buf, str2); : strcat(buf, str3); : without overflowing buf. This

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Warner Losh
In message 199907152329.qaa01...@dingo.cdrom.com Mike Smith writes: : Ugh. Take the first example in the paper; it rewrites as : : len = asprintf(path, %s/.foorc); : : as opposed to : : strlcat(path, homedir, sizeof(path)); : strlcat(path, /, sizeof(path)); :

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Mike Smith
In message 199907152358.qaa01...@dingo.cdrom.com Mike Smith writes: : if (strlen(buf) = sizeof(buf)) : return(error); This can never be true with the strl functions They don't run off the end, so strlen(buf) is always going to be sizeof(buf) since it doesn't include

Re: gdb instead of adb

1999-07-15 Thread Greg Lehey
On Wednesday, 14 July 1999 at 22:45:32 -0700, Mike Smith wrote: Is the reason why adb hasn't been ported to freebsd because the source is proprietary? You make no sense. What don't you understand? It makes plenty of sense to me (and the answer is: yes). If gdb should suffice for my

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Warner Losh
In message 19990715194203.a54...@mad Tim Vanderhoek writes: : Looking at OpenBSD's actual definition of strlcat() which returns the : number of chars that would have been in the final string is : potentially non-useful, but not really too terrible. No. It is useful. If you look at the

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Warner Losh
In message 199907160023.raa02...@dingo.cdrom.com Mike Smith writes: : I still think this is the wrong way to deal with the problem. 8) We mildly disagree here. The strl* functions are the end all, be all of security. They are just designed to make the existing code that uses static buffers easy

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Warner Losh
In message 199907160032.saa01...@harmony.village.org Warner Losh writes: : We mildly disagree here. The strl* functions are the end all, be all : of security. NOTE: This should have read: We mildly disagree here. The strl* functions are NOT the end all, be all of security. which changes its

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Sheldon Hearn
On Thu, 15 Jul 1999 18:28:52 CST, Warner Losh wrote: I'm planning on committing their man page. I don't see problems with it, purhaps people could point them out to me so that both our man pages and theirs could be better. As I've said already, there's too much in DESCRIPTION that should

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Mike Smith
In message 199907160023.raa02...@dingo.cdrom.com Mike Smith writes: : I still think this is the wrong way to deal with the problem. 8) We mildly disagree here. The strl* functions are the end all, be all of security. They are just designed to make the existing code that uses static

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Warner Losh
In message 81768.932085...@axl.noc.iafrica.com Sheldon Hearn writes: : If you see my point, let me know and I'll send you an alternative : strlcpy.3 . I can see your point. I don't know if I'll like your man pages better or not, but I'd be willing to give them a spin. Warner To Unsubscribe:

Re: make fails in 3.2-RELEASE for netboot

1999-07-15 Thread Robert Nordier
I found it when I went searching however I still can't get the netboot to compile as it was designed for aout. Any ideas of why it wasn't moved to elf along with the rest of the OS? Or if not how *I* can port it to elf instead? The intention is that loader(8) will provide the same

Re: Swap overcommit

1999-07-15 Thread Daniel C. Sobral
Andrew Reilly wrote: On Thu, Jul 15, 1999 at 11:48:41PM +0900, Daniel C. Sobral wrote: Actually, applications are written assuming that malloc() will not fail, generally speaking. Is this really the case? I'm pretty sure I've _never_ ignored the possibility of a NULL return from

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Joe Greco
but what about While ( more data items) { copy data items onto end of buffer if full{ write out buffer clear buffer, copy in rest of last item. } } I'd certainly not want to use xxprintf() for that This is what stdio does, funnily enough. See

re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread matthew green
All I want for Christmas is a knob to disable overcommit. And what I'm pretty sure the majority of the readers on this list want is for those of you who really think it's necessary to do it yourselves. What? Nobody who wants to disable the policy knows how to do it? Hmmm,

Re: Advice on deriving accurate time values from the kernel?

1999-07-15 Thread Louis A. Mamakos
I've done some work on measuring things like interrupt response times and the interval between two interesting events or steps in processing. A cheap way to do this is to use the TSC register in the CPU, though you then need to calibrate the frequency that the CPU really runs at. If you're

Re: matcd on an SB16

1999-07-15 Thread Mark Newton
Mike Smith wrote: Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone have any estimate of the amount of effort that'd be required to fix it? It works for some definitions of work. Firstly, there are three different CDROM interfaces that can be hung off an SB16;

re: HELP!! Slice info disappeared

1999-07-15 Thread Kazukiyo UEDA
Hello Niall and Josef, Thanks for your great help. Finally I get all data on the disk back after the struggle on the weekend :) I run the program you sent me, but I got nothing from it. I guess the reason as follows: (1) The program fetches each chunks of 16 blocks from the disk and check if

VMWare plug/quickie tests.

1999-07-15 Thread Jaye Mathisen
I've been running VM Ware under NT for a few days now, booting FreeBSD and other OS's. In some quick testing: The host machine is NT 4.0, SP5, 384MB RAM, dual 450 PII's. The guest OS is FreeBSD 3.2-RELEASE, configured with the VMWARE 512MB disk, and 32MB RAM allocated Compiling a generic

predictability in an unpredictable world

1999-07-15 Thread Anthony Kimball - High Performance Computing
If there were a mechanism whereby one could opt out of the SIGKILL, most if not all of the complaints would go away. SIGDANGER would suffice, but even a rude hack would do in a pinch, such as the one included below (untested). If you mmap real disk instead of sbrk'ing, and use this procfs

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread lyndon
And what I'm pretty sure the majority of the readers on this list want is for those of you who really think it's necessary to do it yourselves. What? Nobody who wants to disable the policy knows how to do it? Hmmm, I wonder whether that's significant... Sheldon, if you can't contribute

Re: Swap overcommit

1999-07-15 Thread Matthew Dillon
: fail, generally speaking. : :Is this really the case? I'm pretty sure I've _never_ ignored the :possibility of a NULL return from malloc, and I've been using it :for nearly 20 years. I usually print a message and exit, but I :never ignore it. I thought that was pretty standard practise. :

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Matthew Dillon
: In that scenario, the 512MB of swap I assigned to this machine would be : dangerously low. : :With 13GB disks available for a couple of hundred bucks, my machines aren't :going to run out of swap space any time soon, even if I commit to disk. : :All I want for Christmas is a knob to

Re: OpenBSD's strlcpy(3) and strlcat(3)

1999-07-15 Thread Bakul Shah
Any use of str{,n}cat makes me gag. In the past I have used a composable function that may be of interest. Composable in the sense that the result can be immediately used as an arg to another call and it doesn't have the O(N^2) behavior of strcat. Such a function can be totally safe. Something

Re: Swap overcommit

1999-07-15 Thread Brian F. Feldman
On Thu, 15 Jul 1999, Matthew Dillon wrote: The are dozens of libc routines which call malloc internally and return allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(), and so forth. Dozens. And while we might check some of these for NULL, we don't

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Daniel C. Sobral
Technical follow-up: Contrary to what I previously said, a number of tests reveal that Solaris, indeed, does not overcommit. All non-read only segments, and all malloc()ed memory is reserved upon exec() or fork(), and the reserved memory is not allowed to exceed the total memory. It makes

Re: Swap overcommit

1999-07-15 Thread Matthew Dillon
: The are dozens of libc routines which call malloc internally and return : allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(), : and so forth. Dozens. And while we might check some of these for NULL, : we don't check them all, and the ones we do check we

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Matthew Dillon
:Technical follow-up: : :Contrary to what I previously said, a number of tests reveal that :Solaris, indeed, does not overcommit. All non-read only segments, :and all malloc()ed memory is reserved upon exec() or fork(), and the :reserved memory is not allowed to exceed the total memory. It makes

Re: Swap overcommit

1999-07-15 Thread Kevin Day
: The are dozens of libc routines which call malloc internally and return : allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(), : and so forth. Dozens. And while we might check some of these for NULL, : we don't check them all, and the ones we do

implementing poll() in a device driver (fwd)

1999-07-15 Thread Vasudha Ramnath
Got no response from freebsd-questions. can anyone here help ? Please cc your reply to my email a/c. thanks --Vasudha -- Forwarded message -- Date: Thu, 15 Jul 1999 14:42:34 +0800 (SGT) From: Vasudha Ramnath v...@krdl.org.sg To: freebsd-questi...@freebsd.org Subject:

Re: Swap overcommit

1999-07-15 Thread David E. Cross
No, wait, I got that wrong I think. Oh yah, I remember now. Hmm. How odd. I came across a case where read() could return -1 and not set errno properly if errno was already set, but a perusal of the kernel code seems to indicate that this can't happen. Very

<    1   2