Re: setiathome crashes 3.2?
On Sun, Jun 27, 1999 at 10:09:22PM -0400, Thomas David Rivers wrote: I seem to recall seeing this someone (this may not be the right list.) But - I downloaded the 3.2 Seti@home and starting running it on a left-over 75mhz laptop I have. It seems to crash the laptop (silently lock it up, actually) fairly quickly. Did I recall someone else mentioning that? Would everyone agree that it's not a "good thing" for a user-mode program to be able to lock up the OS? There are severall resons. One of them is that I got panics with a to high set MAXUSER in kernel options. I don't know if it's a problem with 3.2. The other possible reason might be a CPU overheating. CPUs used under FreeBSD are typicall suspended during idle-time - when running seti or other permanent running programms there is no idle time. I asume there are several more possbilities. But it sounds like there is something broken with your configuration. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
restricted kernel threads implementation from NetBSD via newconfig
I'd like to bring a kernel thread implementation, ported from NetBDS by the newconfig project, into the kernel. Who would like to review things before they go into the tree? I can see many benefits for having this in the tree, but very little downside. This should allow people to more easily port raid-frame from NetBSD if they desire. FYI, this is an outshoot of the porting of the newconfig code to new-bus. Each bridge controller has its own even thread to handle cards events in a sane manner. It is basically a stripped down pccardd in the kernel, but one that has a huge hint database. I'm not proposing, at this time, to bring it on. I just want to get the kthread stuff in as a separate issue. Comments? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: restricted kernel threads implementation from NetBSD via newconfig
:please yes.. :eventually we'll be using it to fire off a thread for every interrupt :source if we go the BSDI way. (as dicussed with various people at USENIX) : :I was actually thinking about this today... : :now this is threads within the kernel, and not kernel support for user :threads right? : :julian I think we desparately need a kernel threads implementation. *Any* implementation, so we can start messing around with it! Even if it isn't the one we eventually choose. Once we have something we can add interrupt-thread support to it and then move some of the more innocuous interrupt-based device drivers over to it to generate test cases for the various SMP mechanisms people have been discussing. I was thinking, specifically, of moving a few of the ethernet devices, which tend to have relatively simplistic interrupt-level code - a perfect test case for us because it will be fairly easy to port and fairly easy to measure performance under load. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Improving the Unix API
flink (make a new directory link for file given by descriptor), flink() combined with the ability to create an unlinked file in a given filesystem would allow for safe temporaries without race conditions, that could be "published" when ready. The System V people (Solaris, Unixware) call this fattach(). ; Bodo -- Bodo Rüskamp, [EMAIL PROTECTED], 51°55' N 7°41' E (1) Elvis is alive. (2) Dinosaurs too. http://www.lochness.scotland.net/camera.htm (3) The next millenium starts on January 1st 2000. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: restricted kernel threads implementation from NetBSD via n
On 28-Jun-99 Matthew Dillon wrote: I think we desparately need a kernel threads implementation. *Any* implementation, so we can start messing around with it! Even if it isn't the one we eventually choose. I don't suppose someone could post an explanation of how kernel threads work could they? :) I sort of grasp the idea but I'm wondering what passes for context switches and stuff like that.. What does the switching between threads etc? Or am I completely off track? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Re: RE: Implementation of mmap() in FreeBSD
: [ML] It is possible to handle these cases in VM code, by : trapping on any access to the partial page, and allowing only those : accesses which are withing the originally requested range. Performance : would suck without end, though. : :Well it would only suck for access to that page right, which wouldn't be too :bad unless the program in question thrashes out the partial pages. : :--- :Daniel O'Connor software and network engineer I don't think this would be workable. It would fail utterly on small files -- every single access would be trapped. The system must be reasonably deterministic. Programmers have a reasonable expectation that accesses to mmap'd areas are, for in-core pages, instantanious. Otherwise they wouldn't bother to use mmap and instead would use read() and write() :-) -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setiathome crashes 3.2?
Would everyone agree that it's not a "good thing" for a user-mode program to be able to lock up the OS? There are severall resons. One of them is that I got panics with a to high set MAXUSER in kernel options. I don't know if it's a problem with 3.2. The other possible reason might be a CPU overheating. CPUs used under FreeBSD are typicall suspended during idle-time - when running seti or other permanent running programms there is no idle time. I didn't know that. This laptop does have a fan for the P-75 But, I don't believe it is that problem. You see, I can run it for about 5 minutes and *poof* - the machine is gone. I asume there are several more possbilities. But it sounds like there is something broken with your configuration. I think I'll need to put ddb in the kernel and see what's happening, since I get no panic or anything... - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Improving the Unix API
On Mon, 28 Jun 1999, David S. Miller wrote: Date: Mon, 28 Jun 1999 06:12:44 -0400 (EDT) From: Alexander Viro [EMAIL PROTECTED] 3) openpromfs - sparc only (?), AFAICS not actively maintained. Oh, it's maintained and used every day, believe me. Cool ;-) There is a lot of stuff that is apparently not used in the main tree and vger CVS also gives zero. I'ld like to ask a couple of questions about that code, but let's take it to e-ma^W oh, hell... out of crossposting. And postpone till the evening - I'm going down now... Oh, dear... Integrating all this stuff when the page/buffer cache stuff will settle down is going to be something ;-/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: restricted kernel threads implementation from NetBSD via newconfig
In message [EMAIL PROTECTED] Julian Elischer writes: : now this is threads within the kernel, and not kernel support for user : threads right? Yes. That's right. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: restricted kernel threads implementation from NetBSD via n
In message [EMAIL PROTECTED] "Daniel J. O'Connor" writes: : I don't suppose someone could post an explanation of how kernel threads work : could they? :) Looks like it just does a fork like thing so it can do context switches... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: restricted kernel threads implementation from NetBSD via n
On Mon, 28 Jun 1999, Warner Losh wrote: In message [EMAIL PROTECTED] "Daniel J. O'Connor" writes: : I don't suppose someone could post an explanation of how kernel threads work : could they? :) Looks like it just does a fork like thing so it can do context switches... To be more precise, it should be more like a rfork() like thing that doesn't change any resources except the stack, a process structure and processor context. Specifically, processor VMspace is basically left at whatever it is already at, and there is no 'signal' stuff or file descriptor table munging. We might even allow the MMU to be left unchanged too. julian Warner 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: restricted kernel threads implementation from NetBSD via n
Warner Losh wrote: In message [EMAIL PROTECTED] "Daniel J. O'Connor" writ es: : I don't suppose someone could post an explanation of how kernel threads wor k : could they? :) Looks like it just does a fork like thing so it can do context switches... Warner When I looked last time, it was effectively a callable interface to what we do from SYSINIT_KT(), ie: fork proc0, which runs in kernel space with it's own stack etc. kthread_create_deferred() is not really anything to do with those sort of threads. It's just a generic callback registration system that happens to be called after the basic processes have started so that proc0,1,2 etc are not disturbed. It's similar to the config_intrhook() stuff but is run later. You can probably cut/paste our SYSINIT_KT() code into some compatable function interfaces pretty easily to avoid yet another new file. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
panic: bwrite: buffer is not busy???
I'm recieving this error on a FreeBSD 2.2.x installation with an Adaptac 2940UW and a Seagate hard drive. I have a second machine with the exact same hardware and software setup which is also producing this error (with a lesser frequency). There are, unfortunately, several other machines with the same hardware and similar software which are not producing this error. For now, I'm looking for an explanation of what is error is and where it may be coming from. I found one question very similar to this in the archive, but alas, there was no reply. TIA! --- Mark Rekai - INetU, Inc.(tm) - http://www.INetU.net Electronic commerce - Web development - Web hosting [EMAIL PROTECTED] - Phone: (610) 266-7441 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dynamic linking
On Mon, 28 Jun 1999, Andrew Iltchenko wrote: Hi, Does anyone know if it is possible to figure out the name of a shared object linked using the dlopen call, having only the address returned by dlopen? man dladdr tell me if this helps, thanks. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Implementation of mmap() in FreeBSD
On Mon, 28 Jun 1999, Matthew Dillon wrote: : it is extremely memory efficient. : :I guess you are talking about VMIO buffers where the pages are found and :registered into the buffer header during allocbuf(). When we do I/O on :VMIO buffers using conventional system call method, we specify UIO_NOCOPY :to instruct the uiomove() do not perform data copy. UIO_NOCOPY is used to handle a degenerate case in the VFS/BIO vs VM interaction for I/O, it has nothing to do with the read() or write() syscall per say, nor is it related to the mmap code. : Programmers who use mmap() expect it to be as close to optimal as : possible. : :I write a program to test the mmap() today. It turns out that a user can :modify the part of the mmapped area that is within the system returned :area but not part of the user-specified area. : :As I understand it, there are two access paths to a file: conventional I/O :through read/write systems calls and memory-mapped I/O. Both of them :converge at the vnode read and write routine (VOP_READ() and VOP_WRITE()). :This should give us the opportunity to guard against illegal memory-mapped :I/O writes made by the user. They converge in the VMIO page cache. By converge, I mean VOP_GETPAGES() and VOP_PUTPAGES() will call VOP_READ() and VOP_WRITE() just as read() and write() system call. :Maybe we can add some fields in the vm_object to record the real or :user-specifed area which can be passed to the vnode read and write :routine. In the vnode I/O routine, we should be able to limit the write to :only the orginal part of the area specified by the user. This practice :should not incur any performance loss. : :-Zhihui mmap bypasses the vnode. What you propose will not work because even if the VM object is process-specific, the pages underlying the VM object are not. If several processes are mmap()ing overlapping portions of the file, they are *sharing* the pages. So even though they are not sharing the VM object, the VM system will not be able to tell which process modified the page, and therefore any byte-ranged limits specified in the VM object will be useless. This is a good point! I have never thought of it before. Thanks. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Implementation of mmap() in FreeBSD
On Mon, 28 Jun 1999 12:54:12 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: mmap bypasses the vnode. What you propose will not work because even if the VM object is process-specific, the pages underlying the VM object are not. If several processes are mmap()ing overlapping portions of the file, they are *sharing* the pages. So even though they are not sharing the VM object, the VM system will not be able to tell which process modified the page, and therefore any byte-ranged limits specified in the VM object will be useless. Well, if you make a VM object map-entry-specific (not just "process-specific"; a single process may have multiple mappings of a file!), then the pages *can't* be shared, because pages are owned by the objects. The only reason you can share pages is because multiple map entries may reference the same object (the offset into the object being map-entry-specific). Put another way, it's not possible for this sentence to be true, at all: What you propose will not work because even if the VM object is process-specific, the pages underlying the VM object are not. ...since the presence of map-entry-specific objects would make the pages also map-entry-specific by definition. This, of course, would mean that VM objects themselves serve no purpose, so you could collapse it into "pages are owned by VM map entries", and do away with objects completely. However, that would be stupid. Anyhow, it's possible to have the semantics Zhihui suggested, but you have to give up an awful lot to get them. :-) -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Implementation of mmap() in FreeBSD
:Well, if you make a VM object map-entry-specific (not just "process-specific"; :a single process may have multiple mappings of a file!), then the pages :*can't* be shared, because pages are owned by the objects. The only reason :you can share pages is because multiple map entries may reference the same :object (the offset into the object being map-entry-specific). : :Put another way, it's not possible for this sentence to be true, at all: : : What you propose will not work because even if the VM object is : process-specific, the pages underlying the VM object are not. There's missing information. Remember that VM objects are recursive. That is, they stack in layers. So, in fact, you are sharing the same physical page for both a PRIVATE and SHARED mmap. A copy only occurs if you attempt to modify a page in a PRIVATE mmap. The underlying VM object is, ultimately, the file itself. That's what I meant. You are absolute correct about the high-level mapping occuring in the map-entry. For a shared map it is ultimately the same VM object. :This, of course, would mean that VM objects themselves serve no purpose, so :you could collapse it into "pages are owned by VM map entries", and do away :with objects completely. : :However, that would be stupid. : :Anyhow, it's possible to have the semantics Zhihui suggested, but you have to :give up an awful lot to get them. :-) : :-- Jason R. Thorpe [EMAIL PROTECTED] It really isn't possible without creating massive inefficiencies. It would be possible in a MULTICS system, but not in a UNIX system and not with most modern processors ( which do not have byte resolved variable-length page maps ). Not efficiently, anyway. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Implementation of mmap() in FreeBSD
: :By converge, I mean VOP_GETPAGES() and VOP_PUTPAGES() will call VOP_READ() :and VOP_WRITE() just as read() and write() system call. Yes, but what they are doing is mapping the VMIO cache pages into the buffer, so the VOP_READ/VOP_WRITE essentially operates directly on the VMIO cache pages. This is why NOCOPY is set -- because there is no need to copy the data from the buffer to the VMIO cache because the buffer IS the VMIO cache at that point in time. Confusing, eh? A normal read() or write() syscall always copies the data, because the uio buffer in that case is not VMIO cache but instead some location in the processor's memory. Even if this location were associated with an mmap(), it would almost certainly be to a different file so the copy must occur anyway. A lot of the apparent confusion in the code is due to the fact that the code did not originally implemented a unified buffer cache. It is being slowly cleaned up. :-Zhihui -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RPLd or rplboot
Has anyone ever seen an open implementation of RPL, remote program load ? Or at paper specification of it against which one could write such a beast ? http://www.freebsd/org/~msmith/documents/RPL BTW, did you get your box? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
A way to crash system (3.1 3.2) with floppy
Suppose you have a *write-protected* DOS floppy and you do: # mount -t msdos /dev/fd0 /floppy -- this is OK # cp somefile /floppy -- a lot of error messages # umount /floppy -- crash Now the system tries to sync the dirty buffers and fails. You have to press a key to reboot. Is there anything wrong here or FreeBSD simply does not handle this in a more elegant way? Thanks for any help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
I wanted t know where the environment strings i bsd were stored after a program execs another one. extern char **environ; At the top of memory. You can access them by the standard (but undocumented) method: int main (int argc, char *argv [], char *envp []) envp is a pointer to the environment strings. This is true for every version of UNIX I know. This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). Besides, the `envp' argument is a recommended extension in ISO/ANSI C, so you can hardly say that it's undocumented. l8r, patryk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
On Tuesday, 29 June 1999 at 12:18:07 +1000, Patryk Zadarnowski wrote: I wanted t know where the environment strings i bsd were stored after a program execs another one. extern char **environ; At the top of memory. You can access them by the standard (but undocumented) method: int main (int argc, char *argv [], char *envp []) envp is a pointer to the environment strings. This is true for every version of UNIX I know. This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). This is news to me. Can you point to the documentation? Besides, the `envp' argument is a recommended extension in ISO/ANSI C, so you can hardly say that it's undocumented. Hmm. I don't have the Standard here, but I've dug around and found a couple of references to the third parameter, an "optional extension". I think the real problem is that KR didn't describe it: it was introduced in the Seventh Edition, which came after KR. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). This is news to me. Can you point to the documentation? I'll sniff around and get back to you (read: I'll ask our local guru on PDP-11's and other ancient rituals, who told me about those in the first place.) l8r, patryk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
On Tue, 29 Jun 1999, Greg Lehey wrote: This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). This is news to me. Can you point to the documentation? Besides, the `envp' argument is a recommended extension in ISO/ANSI C, so you can hardly say that it's undocumented. Hmm. I don't have the Standard here, but I've dug around and found a couple of references to the third parameter, an "optional extension". I think the real problem is that KR didn't describe it: it was introduced in the Seventh Edition, which came after KR. man 3 exec, I think. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message +--- Chuck Robey | Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
I know about envp. What I want to know is the exact position of these variables on the stack. and if anywhere I can find some data, on the exact compisoition of the stcak, then it will be very helpful. references of books and websites wil be most helpful. amol On Monday, 28 June 1999 at 5:54:29 -0400, Amol Mohite wrote: Hi! i hope this is the right list for this qs. I wanted t know where the environment strings i bsd were stored after a program execs another one. At the top of memory. You can access them by the standard (but undocumented) method: int main (int argc, char *argv [], char *envp []) envp is a pointer to the environment strings. This is true for every version of UNIX I know. Is there any place I ca get hold of the ABIs for freebsd ? Can you be more specific? Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
On Monday, 28 June 1999 at 23:32:59 -0400, Amol Mohite wrote: On Monday, 28 June 1999 at 5:54:29 -0400, Amol Mohite wrote: Hi! i hope this is the right list for this qs. I wanted t know where the environment strings i bsd were stored after a program execs another one. At the top of memory. You can access them by the standard (but undocumented) method: int main (int argc, char *argv [], char *envp []) envp is a pointer to the environment strings. This is true for every version of UNIX I know. Is there any place I ca get hold of the ABIs for freebsd ? Can you be more specific? I know about envp. What I want to know is the exact position of these variables on the stack. As I said, at the top. and if anywhere I can find some data, on the exact compisoition of the stcak, then it will be very helpful. references of books and websites wil be most helpful. I think that, for FreeBSD, the source is the only place you'll find it. There's a brief description in "Porting UNIX Software" (http://www.ora.com/catalog/port/noframes.html), but that's not specific to FreeBSD. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
I know about envp.
What I want to know is the exact position of these variables on the stack.
and if anywhere I can find some data, on the exact compisoition of the
stcak, then it will be very helpful.
references of books and websites wil be most helpful.
Basically, i386 BSD kernels (you're after i386, aren't you?) point ESP to
the following "struct" (which means that it will be dumped at the very
top of the address space)
struct kframe {
int argc; /* "argc" to be passed to main() */
char *argv[argc]; /* "argv" to be passed to main() */
char *null; /* a NULL pointer terminating argv[] */
char **envp;/* value to be assigned to "environ" */
};
/usr/src/lib/csu/i386/crt0.c is probably the best reference you can get
your hands on ;)
Patryk.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: restricted kernel threads implementation from NetBSD via n
In message [EMAIL PROTECTED] "Daniel J. O'Connor" writes: : I don't suppose someone could post an explanation of how kernel threads work : could they? :) In a nutshell, it appears to basically do an rfork. It then becomes like any other process that is interrupted in the kernel... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setiathome crashes 3.2?
On Sun, Jun 27, 1999 at 10:09:22PM -0400, Thomas David Rivers wrote: I seem to recall seeing this someone (this may not be the right list.) But - I downloaded the 3.2 s...@home and starting running it on a left-over 75mhz laptop I have. It seems to crash the laptop (silently lock it up, actually) fairly quickly. Did I recall someone else mentioning that? Would everyone agree that it's not a good thing for a user-mode program to be able to lock up the OS? There are severall resons. One of them is that I got panics with a to high set MAXUSER in kernel options. I don't know if it's a problem with 3.2. The other possible reason might be a CPU overheating. CPUs used under FreeBSD are typicall suspended during idle-time - when running seti or other permanent running programms there is no idle time. I asume there are several more possbilities. But it sounds like there is something broken with your configuration. -- B.Walter COSMO-Project http://www.cosmo-project.de ti...@cicely.de Usergroupi...@cosmo-project.de To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
restricted kernel threads implementation from NetBSD via newconfig
I'd like to bring a kernel thread implementation, ported from NetBDS by the newconfig project, into the kernel. Who would like to review things before they go into the tree? I can see many benefits for having this in the tree, but very little downside. This should allow people to more easily port raid-frame from NetBSD if they desire. FYI, this is an outshoot of the porting of the newconfig code to new-bus. Each bridge controller has its own even thread to handle cards events in a sane manner. It is basically a stripped down pccardd in the kernel, but one that has a huge hint database. I'm not proposing, at this time, to bring it on. I just want to get the kthread stuff in as a separate issue. Comments? Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: restricted kernel threads implementation from NetBSD via newconfig
please yes.. eventually we'll be using it to fire off a thread for every interrupt source if we go the BSDI way. (as dicussed with various people at USENIX) I was actually thinking about this today... now this is threads within the kernel, and not kernel support for user threads right? julian On Mon, 28 Jun 1999, Warner Losh wrote: I'd like to bring a kernel thread implementation, ported from NetBDS by the newconfig project, into the kernel. Who would like to review things before they go into the tree? I can see many benefits for having this in the tree, but very little downside. This should allow people to more easily port raid-frame from NetBSD if they desire. FYI, this is an outshoot of the porting of the newconfig code to new-bus. Each bridge controller has its own even thread to handle cards events in a sane manner. It is basically a stripped down pccardd in the kernel, but one that has a huge hint database. I'm not proposing, at this time, to bring it on. I just want to get the kthread stuff in as a separate issue. Comments? Warner 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: restricted kernel threads implementation from NetBSD via newconfig
:please yes.. :eventually we'll be using it to fire off a thread for every interrupt :source if we go the BSDI way. (as dicussed with various people at USENIX) : :I was actually thinking about this today... : :now this is threads within the kernel, and not kernel support for user :threads right? : :julian I think we desparately need a kernel threads implementation. *Any* implementation, so we can start messing around with it! Even if it isn't the one we eventually choose. Once we have something we can add interrupt-thread support to it and then move some of the more innocuous interrupt-based device drivers over to it to generate test cases for the various SMP mechanisms people have been discussing. I was thinking, specifically, of moving a few of the ethernet devices, which tend to have relatively simplistic interrupt-level code - a perfect test case for us because it will be fairly easy to port and fairly easy to measure performance under load. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Improving the Unix API
flink (make a new directory link for file given by descriptor), flink() combined with the ability to create an unlinked file in a given filesystem would allow for safe temporaries without race conditions, that could be published when ready. The System V people (Solaris, Unixware) call this fattach(). ; Bodo -- Bodo Rüskamp, b...@rueskamp.com, 51°55' N 7°41' E (1) Elvis is alive. (2) Dinosaurs too. http://www.lochness.scotland.net/camera.htm (3) The next millenium starts on January 1st 2000. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Improving the Unix API
Bodo Rueskamp wrote: flink (make a new directory link for file given by descriptor), flink() combined with the ability to create an unlinked file in a given filesystem would allow for safe temporaries without race conditions, that could be published when ready. The System V people (Solaris, Unixware) call this fattach(). fattach is used to implement stream mounts. it does not attach an arbitrary file back to the filesystem. fattach is a library function that specifically mounts a stream pipe using the namefs filesystem. the effect of fattach does not persist across a reboot. jan-simon. ; Bodo -- Bodo Rüskamp, b...@rueskamp.com, 51°55' N 7°41' E To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: restricted kernel threads implementation from NetBSD via n
On 28-Jun-99 Matthew Dillon wrote: I think we desparately need a kernel threads implementation. *Any* implementation, so we can start messing around with it! Even if it isn't the one we eventually choose. I don't suppose someone could post an explanation of how kernel threads work could they? :) I sort of grasp the idea but I'm wondering what passes for context switches and stuff like that.. What does the switching between threads etc? Or am I completely off track? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum pgpDZovejwcjf.pgp Description: PGP signature
RE: Implementation of mmap() in FreeBSD
: :All these situations seem to me are not handled by FreeBSD mmap() code. I :hope I am wrong. I also wonder why we can not add some information to the No machine's mmap() code handles these situations. It is a side effect of the way MMU's work and the way mmap() was defined - that is, in order for mmap() to be reasonably optimal it has to munge the boundry conditions. It is an explicitly allowed case. [ML] It is possible to handle these cases in VM code, by trapping on any access to the partial page, and allowing only those accesses which are withing the originally requested range. Performance would suck without end, though. /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: Implementation of mmap() in FreeBSD
On 28-Jun-99 Ladavac Marino wrote: [ML] It is possible to handle these cases in VM code, by trapping on any access to the partial page, and allowing only those accesses which are withing the originally requested range. Performance would suck without end, though. Well it would only suck for access to that page right, which wouldn't be too bad unless the program in question thrashes out the partial pages. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum pgplomTl7oU9c.pgp Description: PGP signature
RE: synch primitives
-Original Message- From: Wes Peters [mailto:w...@softweyr.com] Sent: Friday, 25 June, 1999 23:46 To: Aaron Smith Cc: Alfred Perlstein; Brian F. Feldman; Karl Denninger; hack...@freebsd.org Subject: Re: synch primitives (was Re: Microsoft performance) Here's a couple of good research points: And of course: Unix Systems for Modern Architectures: Symmetric Multiprocesssing and Caching for Kernel Programmers, Curt Schimmel, September 1994, Addison-Wesley Pub Co; ISBN: 0201633388 -- Hans Zuidam h.zui...@computer.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: restricted kernel threads implementation from NetBSD via n
: :I don't suppose someone could post an explanation of how kernel threads work :could they? :) : :I sort of grasp the idea but I'm wondering what passes for context switches and :stuff like that.. What does the switching between threads etc? Or am I :completely off track? : :--- :Daniel O'Connor software and network engineer Basically switching between kernel threads is the same as switching between processes except that you do not need to mess with the MMU or other complex scheduling elements, so switching between kernel threads can be made almost as fast as a simple subroutine call. A kernel thread can be thought of as a cheaper process. Threads are often called tasks. The terminology is the same, but still distinct from process. This is key to being able to vector an interrupt to a kernel thread. The interrupt code must already save much of the process context, adding a little extra glue to turn it into a kernel thread that we can actually switch-away from should theoretically be very cheap. -Matt Matthew Dillon dil...@backplane.com :for Genesis Software - http://www.gsoft.com.au :The nice thing about standards is that there :are so many of them to choose from. : -- Andrew Tanenbaum : :--_=XFMail.1.3.p0.FreeBSD:990628173909:1295=_ :Content-Type: application/pgp-signature : :-BEGIN PGP MESSAGE- :Version: 2.6.3ia : :iQCVAwUBN3ctpWj0TqzKxF7VAQE5uAP/SDvpI6TZJuDt0FfHfe0Eqp90QD2gjk2R :nTrDhLsP/vMey3Ogsc/LeFNww8woaqXwTD6x3i+04wzkoDvti7rlczi4+2DUfnAj :79lflMw7DdBgd9tYB/3+QTQ3o2BVpT2JZK8zHVX5cPiPKHcPwQl7DhojQeqBx0QU :W7ZKnn2ZYqI= :=SXMo :-END PGP MESSAGE- : :--_=XFMail.1.3.p0.FreeBSD:990628173909:1295=_-- :End of MIME 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: RE: Implementation of mmap() in FreeBSD
: [ML] It is possible to handle these cases in VM code, by : trapping on any access to the partial page, and allowing only those : accesses which are withing the originally requested range. Performance : would suck without end, though. : :Well it would only suck for access to that page right, which wouldn't be too :bad unless the program in question thrashes out the partial pages. : :--- :Daniel O'Connor software and network engineer I don't think this would be workable. It would fail utterly on small files -- every single access would be trapped. The system must be reasonably deterministic. Programmers have a reasonable expectation that accesses to mmap'd areas are, for in-core pages, instantanious. Otherwise they wouldn't bother to use mmap and instead would use read() and write() :-) -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Improving the Unix API
On Sun, 27 Jun 1999, Alexander Viro wrote: On Mon, 28 Jun 1999, Doug Rabson wrote: I'm talking about the concept of a header file containing something like: #define FL_VFS 0 #define FL_FOOFS1 #define FD_BARFS2 ... not being scalable. Do you have a complete list of filesystem types? Are you prepared to act as an Assigned Number authority for that list. For this kind of problem, strings are a damn sight easier to manage in the long term. Augh... It's ugly, indeed, but... sysctl() is not much nicer and all systems in question manage to deal with it somehow. OTOH doing it as strings... Hell knows. I'll look at it. Considering that HFS folks had already asked for more than one value here (creator and type?) it may be reasonable. I'm afraid that doing that may open the hell gates ;-/ 'N' in *ANA can be 'namespace' as well as 'number'... Its a tough one alright. Some of my friends at Microsoft would suggest using UUIDs for this job. They might be clumsy but at least they are never going to collide and they are easy to generate. As far as sysctl goes, FreeBSD deprecates the use of numbers for OIDs and has a string-based mechanism for exploring the sysctl tree. asbestos underware[1] BTW, how does NetBSD deal with HFS cough forks? /asbestos underware [1] cue current flamew^Wthreads on l-k regarding files-as-directories hell. :-) -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Beating system usage down
On Thu, Jun 24, 1999 at 12:34:06PM -0700, Mike Smith wrote: Just for those that have been following the benchmarking thread, this is exactly the same symptom set that FreeBSD demonstrates when loaded by WebBench. The gotcha here is, again, the giant kernel lock. Rather than trying to do the Solaris thing of mutexing everything, why don't we go in the opposite direction, and configure a multi-processor box as a cluster that happens to have really fast communications? Probably not as easy as it sounds, particularly since it would involve writing a memory network device driver, and some boot code to partition the main memory, and probably an extra layer of interrupt handling code, to hand device interrupts around. Er, yuck. It's just that it sounds as though it would be simpler to start with a blank sheet and a clean reentrant scheduling scheme, and graft pieces of FreeBSD back on top, than it would be to add that sort of functionality onto an existing traditionally structured Unix. -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: RE: Implementation of mmap() in FreeBSD
: Otherwise they wouldn't bother to use mmap and instead would use read() : and write() :-) : :Hmm.. why (unless you forced mmap to use the address you gave it) would it not :choose the start address to be on a page boundary? : :--- :Daniel O'Connor software and network engineer Because we can't realign the data in the pages without doing a buffer copy. To force mmap() to align the data to the start of the page requires it to allocate memory and copy the in-core disk cache to the new memory. This is extremely wasteful of cpu and memory. The current UNIX mmap implementation is able to simply map the existing in-core disk cache directly to the process - no buffer copying is required at all, and it is extremely memory efficient. Programmers who use mmap() expect it to be as close to optimal as possible. Also, even if we were to realign the data, it would not deal with the end-of-data case. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On Sun 1999-06-27 (22:26), John Baldwin wrote: if people have their undies in a wad over this, can't they compile inetd without LIBWRAP? Ahem.. Let's say I have two services, foo and bar, with food and bard. I want to wrap food, but *NOT* bard and they are both in /etc/inetd.conf. How do you propose to solve this with the internal wrapping (which is a good idea, IMO as it eliminates an exec())? Run two copies of inetd? Seriously, if wrapping support can be tuned at runtime, and you can set up inetd to run with different configuration files (which you can), if those people who want to run both wrapped and non-wrapped services agree that this is an option, there needn't be a hack to do this sort of thing. Neil -- Neil Blakey-Milner n...@rucus.ru.ac.za To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Improving the Unix API
As far as sysctl goes, FreeBSD deprecates the use of numbers for OIDs and has a string-based mechanism for exploring the sysctl tree. So we are actually both going the same way. Linus with /proc/sys and his official dislike of sysctl (Oh well I think sysctl using number spaces is the right idea - like snmp is), and BSD going to names To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: Connect and so on..
Essentially, we're trying to mediate system calls. Read, Write, Open, Socket calls from userland are caught, information about the calling process (i.e. caller UID) are sent to an external source for authorization and depending on the reply, the system call will proceed or not. This is the reason why the connection should be atomic and (so I think) in the kernel. Can't have other calls going through in the interim. [ML] If I understand this correctly, only the syscall which is being authenticated must block during the authentication. This makes the authentication atomic from the viewpoint of the syscall. The other processes/kernel supported threads may proceed. Sounds like RAGF(spelling?) scheme you're doing there. NFS daemon approach may be feasible for you, because this is exactly what it does. You have one central authentication daemon which is blocked in kernel syscall all the time, unless some other process (syscall) requests the authentication. The daemon then returns to user space, performs the neccessary authentication, and goes back into kernel with results. This is the way I would implement it, because it makes adding authentication schemes rather simple. [ML] /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Improving the Unix API
On Mon, 28 Jun 1999, Alan Cox wrote: As far as sysctl goes, FreeBSD deprecates the use of numbers for OIDs and has a string-based mechanism for exploring the sysctl tree. So we are actually both going the same way. Linus with /proc/sys and his official dislike of sysctl (Oh well I think sysctl using number spaces is the right idea - like snmp is), and BSD going to names As far as I know, only FreeBSD has a string-based sysctl implementation. Something which always confused me about Linux' procfs - what have all these kernel variables got to do with process state? We used to have a kernfs which was intended for this kind of thing but it rotted after people started extending sysctl for the purpose. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Improving the Unix API
On Mon, 28 Jun 1999, Alan Cox wrote: As far as sysctl goes, FreeBSD deprecates the use of numbers for OIDs and has a string-based mechanism for exploring the sysctl tree. So we are actually both going the same way. Linus with /proc/sys and his official dislike of sysctl (Oh well I think sysctl using number spaces is the right idea - like snmp is), and BSD going to names Yup. kernfs (we'ld also better keep it in a separate fs instead of cluttering procfs, but that's another story). OK, then. I've looked at it and it seems that strings will be easy to do (for new chflags, that is). For the time being I simply #define them to vfs and fs names - choosing decent names will wait until the thing will actually work ;-) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Improving the Unix API
As far as I know, only FreeBSD has a string-based sysctl implementation. Nod. Something which always confused me about Linux' procfs - what have all these kernel variables got to do with process state? We used to have a kernfs which was intended for this kind of thing but it rotted after people started extending sysctl for the purpose. About as much as having a /usr/bin for the slower binaries on the 40Mbyte moving head disk has relationship to /usr nowdays. /proc is basically both process and machine state in Linux. It got expaneded on. Alan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Improving the Unix API
On Mon, 28 Jun 1999, Doug Rabson wrote: As far as I know, only FreeBSD has a string-based sysctl implementation. Something which always confused me about Linux' procfs - what have all these kernel variables got to do with process state? We used to have a Nothing. procfs is a union of 4 filesystems. Historical reasons ;-/ There are: 1) pid/* - per-process stuff. Procfs proper. 2) sys/ - what kernfs should be. I.e. fs interface for sysctl tree. 3) openpromfs - sparc only (?), AFAICS not actively maintained. 4) the rest - mostly information advertised by drivers + kcore + kmsg, etc. Stuff that is not covered by sysctls (/dev/core is a symlink to /proc/kcore. 'nuff said.) They are different code-wise and ought to be separated. As soon as we'll have working unionfs (or at least non-opaque mount) they *will* be separated. kernfs which was intended for this kind of thing but it rotted after people started extending sysctl for the purpose. /proc/sys on Linux. It was stuffed into procfs because at that moment procfs was the only virtual filesystem (and because they shared some code). To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
environment strings
Hi! i hope this is the right list for this qs. I wanted t know where the environment strings i bsd were stored after a program execs another one. Is there any place I ca get hold of the ABIs for freebsd ? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: setiathome crashes 3.2?
Would everyone agree that it's not a good thing for a user-mode program to be able to lock up the OS? There are severall resons. One of them is that I got panics with a to high set MAXUSER in kernel options. I don't know if it's a problem with 3.2. The other possible reason might be a CPU overheating. CPUs used under FreeBSD are typicall suspended during idle-time - when running seti or other permanent running programms there is no idle time. I didn't know that. This laptop does have a fan for the P-75 But, I don't believe it is that problem. You see, I can run it for about 5 minutes and *poof* - the machine is gone. I asume there are several more possbilities. But it sounds like there is something broken with your configuration. I think I'll need to put ddb in the kernel and see what's happening, since I get no panic or anything... - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Improving the Unix API
Date:Mon, 28 Jun 1999 06:12:44 -0400 (EDT) From: Alexander Viro v...@math.psu.edu 3) openpromfs - sparc only (?), AFAICS not actively maintained. Oh, it's maintained and used every day, believe me. Later, David S. Miller da...@redhat.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Improving the Unix API
On Mon, 28 Jun 1999, David S. Miller wrote: Date: Mon, 28 Jun 1999 06:12:44 -0400 (EDT) From: Alexander Viro v...@math.psu.edu 3) openpromfs - sparc only (?), AFAICS not actively maintained. Oh, it's maintained and used every day, believe me. Cool ;-) There is a lot of stuff that is apparently not used in the main tree and vger CVS also gives zero. I'ld like to ask a couple of questions about that code, but let's take it to e-ma^W oh, hell... out of crossposting. And postpone till the evening - I'm going down now... Oh, dear... Integrating all this stuff when the page/buffer cache stuff will settle down is going to be something ;-/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Improving the Unix API
Something which always confused me about Linux' procfs - what have all these kernel variables got to do with process state? We used to have a kernfs which was intended for this kind of thing but it rotted after people started extending sysctl for the purpose. About as much as having a /usr/bin for the slower binaries on the 40Mbyte moving head disk has relationship to /usr nowdays. /proc is basically both process and machine state in Linux. It got expaneded on. Maybe nobody noticed yet that 'proc' is an acronym, and has nothing to do with processes per se. Hmm. 'Portable Runtime Operation Control' might be a useful name expansion, alluding to the fact that the interface works across all supported platforms without byte order problems etc. :-) Patrick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Dynamic linking
Hi, Does anyone know if it is possible to figure out the name of a shared object linked using the dlopen call, having only the address returned by dlopen? Thanks. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
FreeBSD users in Vienna, AT
Anyone out there in Vienna area using/hacking on FreeBSD? How about a raid on Wiednerbrau this weekend? /Marino -- Marino Ladavac, Dipl.-Ing.Metropolitan Datenserviceges.m.b.H e-mail: mlada...@metropolitan.at GSM: +43 676 309 79 67 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: restricted kernel threads implementation from NetBSD via newconfig
In message pine.bsf.3.95.990627233124.8298o-100...@current1.whistle.com Julian Elischer writes: : now this is threads within the kernel, and not kernel support for user : threads right? Yes. That's right. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: restricted kernel threads implementation from NetBSD via n
In message xfmail.990628173909.dar...@dons.net.au Daniel J. O'Connor writes: : I don't suppose someone could post an explanation of how kernel threads work : could they? :) Looks like it just does a fork like thing so it can do context switches... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: restricted kernel threads implementation from NetBSD via n
On Mon, 28 Jun 1999, Warner Losh wrote: In message xfmail.990628173909.dar...@dons.net.au Daniel J. O'Connor writes: : I don't suppose someone could post an explanation of how kernel threads work : could they? :) Looks like it just does a fork like thing so it can do context switches... To be more precise, it should be more like a rfork() like thing that doesn't change any resources except the stack, a process structure and processor context. Specifically, processor VMspace is basically left at whatever it is already at, and there is no 'signal' stuff or file descriptor table munging. We might even allow the MMU to be left unchanged too. julian Warner 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: restricted kernel threads implementation from NetBSD via n
Warner Losh wrote: In message xfmail.990628173909.dar...@dons.net.au Daniel J. O'Connor writ es: : I don't suppose someone could post an explanation of how kernel threads wor k : could they? :) Looks like it just does a fork like thing so it can do context switches... Warner When I looked last time, it was effectively a callable interface to what we do from SYSINIT_KT(), ie: fork proc0, which runs in kernel space with it's own stack etc. kthread_create_deferred() is not really anything to do with those sort of threads. It's just a generic callback registration system that happens to be called after the basic processes have started so that proc0,1,2 etc are not disturbed. It's similar to the config_intrhook() stuff but is run later. You can probably cut/paste our SYSINIT_KT() code into some compatable function interfaces pretty easily to avoid yet another new file. Cheers, -Peter -- Peter Wemm - pe...@freebsd.org; pe...@yahoo-inc.com; pe...@netplex.com.au To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
panic: bwrite: buffer is not busy???
I'm recieving this error on a FreeBSD 2.2.x installation with an Adaptac 2940UW and a Seagate hard drive. I have a second machine with the exact same hardware and software setup which is also producing this error (with a lesser frequency). There are, unfortunately, several other machines with the same hardware and similar software which are not producing this error. For now, I'm looking for an explanation of what is error is and where it may be coming from. I found one question very similar to this in the archive, but alas, there was no reply. TIA! --- Mark Rekai - INetU, Inc.(tm) - http://www.INetU.net Electronic commerce - Web development - Web hosting m...@inetu.net - Phone: (610) 266-7441 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Dynamic linking
On Mon, 28 Jun 1999, Andrew Iltchenko wrote: Hi, Does anyone know if it is possible to figure out the name of a shared object linked using the dlopen call, having only the address returned by dlopen? man dladdr tell me if this helps, thanks. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
unsubscribe
unsubscribe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Improving the Unix API
On Mon, 28 Jun 1999, Francois-Rene Rideau wrote: On Sun, Jun 27, 1999 at 12:58:05PM -0400, der Mouse wrote: See NetBSD (and presumably other BSD) mount -o update,rdonly and/or umount -f. (Last I tried, the latter didn't work as it should, but that's a matter of fixing bugs rather than introducing new features.) If you re-read the original message, the problem is what to do about processes with open file descriptors on the partition: stop them at once? stop them at first file access? block them instead? kill them? Will you do it atomically? How will you allow for such large table-walking to be compatible with real-time kernel response? [Hint: either use incremental data-structures, or don't be atomic and be interruptible instead.] unmount -f is more intended for oh-sh*t situations. So harshness is ok. The way it's done is that all of the vnodes in that fs's vnode list get either vgone'd or vcleaned (in the -f case). This will have the effect of mapping them to deadfs vnodes, so all future access will either fail or do nothing (close works, read returns an error). There aren't any big table walks. :-) Take care, Bill To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
unsubscribe
unsubscribe freebsd-hackers To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: RE: Implementation of mmap() in FreeBSD
Because we can't realign the data in the pages without doing a buffer copy. To force mmap() to align the data to the start of the page requires it to allocate memory and copy the in-core disk cache to the new memory. This is extremely wasteful of cpu and memory. The current UNIX mmap implementation is able to simply map the existing in-core disk cache directly to the process - no buffer copying is required at all, and it is extremely memory efficient. I guess you are talking about VMIO buffers where the pages are found and registered into the buffer header during allocbuf(). When we do I/O on VMIO buffers using conventional system call method, we specify UIO_NOCOPY to instruct the uiomove() do not perform data copy. Programmers who use mmap() expect it to be as close to optimal as possible. I write a program to test the mmap() today. It turns out that a user can modify the part of the mmapped area that is within the system returned area but not part of the user-specified area. As I understand it, there are two access paths to a file: conventional I/O through read/write systems calls and memory-mapped I/O. Both of them converge at the vnode read and write routine (VOP_READ() and VOP_WRITE()). This should give us the opportunity to guard against illegal memory-mapped I/O writes made by the user. Maybe we can add some fields in the vm_object to record the real or user-specifed area which can be passed to the vnode read and write routine. In the vnode I/O routine, we should be able to limit the write to only the orginal part of the area specified by the user. This practice should not incur any performance loss. -Zhihui To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: RE: Implementation of mmap() in FreeBSD
: it is extremely memory efficient. : :I guess you are talking about VMIO buffers where the pages are found and :registered into the buffer header during allocbuf(). When we do I/O on :VMIO buffers using conventional system call method, we specify UIO_NOCOPY :to instruct the uiomove() do not perform data copy. UIO_NOCOPY is used to handle a degenerate case in the VFS/BIO vs VM interaction for I/O, it has nothing to do with the read() or write() syscall per say, nor is it related to the mmap code. : Programmers who use mmap() expect it to be as close to optimal as : possible. : :I write a program to test the mmap() today. It turns out that a user can :modify the part of the mmapped area that is within the system returned :area but not part of the user-specified area. : :As I understand it, there are two access paths to a file: conventional I/O :through read/write systems calls and memory-mapped I/O. Both of them :converge at the vnode read and write routine (VOP_READ() and VOP_WRITE()). :This should give us the opportunity to guard against illegal memory-mapped :I/O writes made by the user. They converge in the VMIO page cache. :Maybe we can add some fields in the vm_object to record the real or :user-specifed area which can be passed to the vnode read and write :routine. In the vnode I/O routine, we should be able to limit the write to :only the orginal part of the area specified by the user. This practice :should not incur any performance loss. : :-Zhihui mmap bypasses the vnode. What you propose will not work because even if the VM object is process-specific, the pages underlying the VM object are not. If several processes are mmap()ing overlapping portions of the file, they are *sharing* the pages. So even though they are not sharing the VM object, the VM system will not be able to tell which process modified the page, and therefore any byte-ranged limits specified in the VM object will be useless. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: RE: Implementation of mmap() in FreeBSD
On Mon, 28 Jun 1999, Matthew Dillon wrote: : it is extremely memory efficient. : :I guess you are talking about VMIO buffers where the pages are found and :registered into the buffer header during allocbuf(). When we do I/O on :VMIO buffers using conventional system call method, we specify UIO_NOCOPY :to instruct the uiomove() do not perform data copy. UIO_NOCOPY is used to handle a degenerate case in the VFS/BIO vs VM interaction for I/O, it has nothing to do with the read() or write() syscall per say, nor is it related to the mmap code. : Programmers who use mmap() expect it to be as close to optimal as : possible. : :I write a program to test the mmap() today. It turns out that a user can :modify the part of the mmapped area that is within the system returned :area but not part of the user-specified area. : :As I understand it, there are two access paths to a file: conventional I/O :through read/write systems calls and memory-mapped I/O. Both of them :converge at the vnode read and write routine (VOP_READ() and VOP_WRITE()). :This should give us the opportunity to guard against illegal memory-mapped :I/O writes made by the user. They converge in the VMIO page cache. By converge, I mean VOP_GETPAGES() and VOP_PUTPAGES() will call VOP_READ() and VOP_WRITE() just as read() and write() system call. :Maybe we can add some fields in the vm_object to record the real or :user-specifed area which can be passed to the vnode read and write :routine. In the vnode I/O routine, we should be able to limit the write to :only the orginal part of the area specified by the user. This practice :should not incur any performance loss. : :-Zhihui mmap bypasses the vnode. What you propose will not work because even if the VM object is process-specific, the pages underlying the VM object are not. If several processes are mmap()ing overlapping portions of the file, they are *sharing* the pages. So even though they are not sharing the VM object, the VM system will not be able to tell which process modified the page, and therefore any byte-ranged limits specified in the VM object will be useless. This is a good point! I have never thought of it before. Thanks. -Zhihui To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RPLd or rplboot
Has anyone ever seen an open implementation of RPL, remote program load ? Or at paper specification of it against which one could write such a beast ? Dw. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Implementation of mmap() in FreeBSD
On Mon, 28 Jun 1999 12:54:12 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: mmap bypasses the vnode. What you propose will not work because even if the VM object is process-specific, the pages underlying the VM object are not. If several processes are mmap()ing overlapping portions of the file, they are *sharing* the pages. So even though they are not sharing the VM object, the VM system will not be able to tell which process modified the page, and therefore any byte-ranged limits specified in the VM object will be useless. Well, if you make a VM object map-entry-specific (not just process-specific; a single process may have multiple mappings of a file!), then the pages *can't* be shared, because pages are owned by the objects. The only reason you can share pages is because multiple map entries may reference the same object (the offset into the object being map-entry-specific). Put another way, it's not possible for this sentence to be true, at all: What you propose will not work because even if the VM object is process-specific, the pages underlying the VM object are not. ...since the presence of map-entry-specific objects would make the pages also map-entry-specific by definition. This, of course, would mean that VM objects themselves serve no purpose, so you could collapse it into pages are owned by VM map entries, and do away with objects completely. However, that would be stupid. Anyhow, it's possible to have the semantics Zhihui suggested, but you have to give up an awful lot to get them. :-) -- Jason R. Thorpe thor...@nas.nasa.gov To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Implementation of mmap() in FreeBSD
:Well, if you make a VM object map-entry-specific (not just process-specific; :a single process may have multiple mappings of a file!), then the pages :*can't* be shared, because pages are owned by the objects. The only reason :you can share pages is because multiple map entries may reference the same :object (the offset into the object being map-entry-specific). : :Put another way, it's not possible for this sentence to be true, at all: : : What you propose will not work because even if the VM object is : process-specific, the pages underlying the VM object are not. There's missing information. Remember that VM objects are recursive. That is, they stack in layers. So, in fact, you are sharing the same physical page for both a PRIVATE and SHARED mmap. A copy only occurs if you attempt to modify a page in a PRIVATE mmap. The underlying VM object is, ultimately, the file itself. That's what I meant. You are absolute correct about the high-level mapping occuring in the map-entry. For a shared map it is ultimately the same VM object. :This, of course, would mean that VM objects themselves serve no purpose, so :you could collapse it into pages are owned by VM map entries, and do away :with objects completely. : :However, that would be stupid. : :Anyhow, it's possible to have the semantics Zhihui suggested, but you have to :give up an awful lot to get them. :-) : :-- Jason R. Thorpe thor...@nas.nasa.gov It really isn't possible without creating massive inefficiencies. It would be possible in a MULTICS system, but not in a UNIX system and not with most modern processors ( which do not have byte resolved variable-length page maps ). Not efficiently, anyway. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: RE: Implementation of mmap() in FreeBSD
: :By converge, I mean VOP_GETPAGES() and VOP_PUTPAGES() will call VOP_READ() :and VOP_WRITE() just as read() and write() system call. Yes, but what they are doing is mapping the VMIO cache pages into the buffer, so the VOP_READ/VOP_WRITE essentially operates directly on the VMIO cache pages. This is why NOCOPY is set -- because there is no need to copy the data from the buffer to the VMIO cache because the buffer IS the VMIO cache at that point in time. Confusing, eh? A normal read() or write() syscall always copies the data, because the uio buffer in that case is not VMIO cache but instead some location in the processor's memory. Even if this location were associated with an mmap(), it would almost certainly be to a different file so the copy must occur anyway. A lot of the apparent confusion in the code is due to the fact that the code did not originally implemented a unified buffer cache. It is being slowly cleaned up. :-Zhihui -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: RPLd or rplboot
Has anyone ever seen an open implementation of RPL, remote program load ? Or at paper specification of it against which one could write such a beast ? http://www.freebsd/org/~msmith/documents/RPL BTW, did you get your box? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
A way to crash system (3.1 3.2) with floppy
Suppose you have a *write-protected* DOS floppy and you do: # mount -t msdos /dev/fd0 /floppy -- this is OK # cp somefile /floppy -- a lot of error messages # umount /floppy -- crash Now the system tries to sync the dirty buffers and fails. You have to press a key to reboot. Is there anything wrong here or FreeBSD simply does not handle this in a more elegant way? Thanks for any help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
On Monday, 28 June 1999 at 5:54:29 -0400, Amol Mohite wrote: Hi! i hope this is the right list for this qs. I wanted t know where the environment strings i bsd were stored after a program execs another one. At the top of memory. You can access them by the standard (but undocumented) method: int main (int argc, char *argv [], char *envp []) envp is a pointer to the environment strings. This is true for every version of UNIX I know. Is there any place I ca get hold of the ABIs for freebsd ? Can you be more specific? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
I wanted t know where the environment strings i bsd were stored after a program execs another one. extern char **environ; At the top of memory. You can access them by the standard (but undocumented) method: int main (int argc, char *argv [], char *envp []) envp is a pointer to the environment strings. This is true for every version of UNIX I know. This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). Besides, the `envp' argument is a recommended extension in ISO/ANSI C, so you can hardly say that it's undocumented. l8r, patryk. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: A way to crash system (3.1 3.2) with floppy
On Mon, 28 Jun 1999, Zhihui Zhang wrote: Suppose you have a *write-protected* DOS floppy and you do: # mount -t msdos /dev/fd0 /floppy -- this is OK # cp somefile /floppy -- a lot of error messages # umount /floppy -- crash Now the system tries to sync the dirty buffers and fails. You have to press a key to reboot. Is there anything wrong here or FreeBSD simply does not handle this in a more elegant way? Thanks for any help. I had this happen to me the other day on my 3.2 system. I thought it was just me because I had mounted the disk several days before and figured I had swapped it out. I also had to reformat the floppy on a Win95 system to make it usable again. Jamie To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
On Tuesday, 29 June 1999 at 12:18:07 +1000, Patryk Zadarnowski wrote: I wanted t know where the environment strings i bsd were stored after a program execs another one. extern char **environ; At the top of memory. You can access them by the standard (but undocumented) method: int main (int argc, char *argv [], char *envp []) envp is a pointer to the environment strings. This is true for every version of UNIX I know. This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). This is news to me. Can you point to the documentation? Besides, the `envp' argument is a recommended extension in ISO/ANSI C, so you can hardly say that it's undocumented. Hmm. I don't have the Standard here, but I've dug around and found a couple of references to the third parameter, an optional extension. I think the real problem is that KR didn't describe it: it was introduced in the Seventh Edition, which came after KR. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). This is news to me. Can you point to the documentation? I'll sniff around and get back to you (read: I'll ask our local guru on PDP-11's and other ancient rituals, who told me about those in the first place.) l8r, patryk. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
On Tue, 29 Jun 1999, Greg Lehey wrote: This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). This is news to me. Can you point to the documentation? Besides, the `envp' argument is a recommended extension in ISO/ANSI C, so you can hardly say that it's undocumented. Hmm. I don't have the Standard here, but I've dug around and found a couple of references to the third parameter, an optional extension. I think the real problem is that KR didn't describe it: it was introduced in the Seventh Edition, which came after KR. man 3 exec, I think. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
I know about envp. What I want to know is the exact position of these variables on the stack. and if anywhere I can find some data, on the exact compisoition of the stcak, then it will be very helpful. references of books and websites wil be most helpful. amol On Monday, 28 June 1999 at 5:54:29 -0400, Amol Mohite wrote: Hi! i hope this is the right list for this qs. I wanted t know where the environment strings i bsd were stored after a program execs another one. At the top of memory. You can access them by the standard (but undocumented) method: int main (int argc, char *argv [], char *envp []) envp is a pointer to the environment strings. This is true for every version of UNIX I know. Is there any place I ca get hold of the ABIs for freebsd ? Can you be more specific? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
On Monday, 28 June 1999 at 23:32:59 -0400, Amol Mohite wrote: On Monday, 28 June 1999 at 5:54:29 -0400, Amol Mohite wrote: Hi! i hope this is the right list for this qs. I wanted t know where the environment strings i bsd were stored after a program execs another one. At the top of memory. You can access them by the standard (but undocumented) method: int main (int argc, char *argv [], char *envp []) envp is a pointer to the environment strings. This is true for every version of UNIX I know. Is there any place I ca get hold of the ABIs for freebsd ? Can you be more specific? I know about envp. What I want to know is the exact position of these variables on the stack. As I said, at the top. and if anywhere I can find some data, on the exact compisoition of the stcak, then it will be very helpful. references of books and websites wil be most helpful. I think that, for FreeBSD, the source is the only place you'll find it. There's a brief description in Porting UNIX Software (http://www.ora.com/catalog/port/noframes.html), but that's not specific to FreeBSD. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
I know about envp.
What I want to know is the exact position of these variables on the stack.
and if anywhere I can find some data, on the exact compisoition of the
stcak, then it will be very helpful.
references of books and websites wil be most helpful.
Basically, i386 BSD kernels (you're after i386, aren't you?) point ESP to
the following struct (which means that it will be dumped at the very
top of the address space)
struct kframe {
int argc; /* argc to be passed to main() */
char *argv[argc]; /* argv to be passed to main() */
char *null; /* a NULL pointer terminating argv[] */
char **envp;/* value to be assigned to environ */
};
/usr/src/lib/csu/i386/crt0.c is probably the best reference you can get
your hands on ;)
Patryk.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
On Tuesday, 29 June 1999 at 14:44:39 +1000, Patryk Zadarnowski wrote:
I know about envp.
What I want to know is the exact position of these variables on the stack.
and if anywhere I can find some data, on the exact compisoition of the
stcak, then it will be very helpful.
references of books and websites wil be most helpful.
Basically, i386 BSD kernels (you're after i386, aren't you?) point ESP to
the following struct (which means that it will be dumped at the very
top of the address space)
struct kframe {
int argc; /* argc to be passed to main() */
char *argv[argc]; /* argv to be passed to main() */
char *null; /* a NULL pointer terminating argv[] */
char **envp;/* value to be assigned to environ */
};
In fact, the environment strings are at the very top, followed by the
arguments, followed by this structure. But I suppose that's what you
meant to say.
Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: restricted kernel threads implementation from NetBSD via n
In message xfmail.990628173909.dar...@dons.net.au Daniel J. O'Connor writes: : I don't suppose someone could post an explanation of how kernel threads work : could they? :) In a nutshell, it appears to basically do an rfork. It then becomes like any other process that is interrupted in the kernel... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
Greg Lehey wrote: On Tuesday, 29 June 1999 at 12:18:07 +1000, Patryk Zadarnowski wrote: This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). This is news to me. Can you point to the documentation? Besides, the `envp' argument is a recommended extension in ISO/ANSI C, so you can hardly say that it's undocumented. Hmm. I don't have the Standard here, but I've dug around and found a couple of references to the third parameter, an optional extension. I think the real problem is that KR didn't describe it: it was introduced in the Seventh Edition, which came after KR. Time for a main() man page? Where would it go? Section 2, 3, or 9? Hmm... -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
