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
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
: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?
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
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
: [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
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
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
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
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
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
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
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
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
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
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
: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
:
: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
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
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
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
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
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
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
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
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
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
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
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
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
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?
: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?
:
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
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
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
:
: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 -
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
-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
:
: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
: [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
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.
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
: 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
unsubscribe
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
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
unsubscribe freebsd-hackers
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
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
: 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
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
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
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
: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
:
: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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
87 matches
Mail list logo
