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 AT&T UNIX ev
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 AT&T UNIX eve
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
In message "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 m
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.
>>
>>
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.
>>
>> r
> 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 k
> 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 ke
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 on
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
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
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 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 AT&T UNIX even has a
> > (documented) five-parameter main().
>
> Thi
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 AT&T UNIX even has a
> > (documented) five-parameter main().
>
> This
> > 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 AT&T UNIX even has a
> > (documented) five-parameter main().
>
> This is news to me. Can you point to the
> > 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 AT&T UNIX even has a
> > (documented) five-parameter main().
>
> This is news to me. Can you point to the d
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
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:
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 buffe
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 buffer
> > 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 poin
> > 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 point
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
undocumente
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
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 ther
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
>
> 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
>
> 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
:
: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 cach
: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 t
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 ove
:
: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
: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 th
On Mon, 28 Jun 1999 12:54:12 -0700 (PDT)
Matthew Dillon 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
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,
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 [EMAIL PROTECTED]
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
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, 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, w
:> 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
>
> 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
unsubscribe freebsd-hackers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
unsubscribe freebsd-hackers
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 rath
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 rathe
unsubscribe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
unsubscribe
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
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, 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 ma
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 t
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 th
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 looke
Warner Losh wrote:
> In message "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
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
On Mon, 28 Jun 1999, Warner Losh wrote:
> In message "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 shou
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 "un
In message "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 freebs
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
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
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: [EMAIL PROTECTED]
GSM: +43 676 309 79 67
To Unsubscribe: send mail to [EMAIL PROTECTED]
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...@f
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
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
> > 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
> > 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
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 l
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.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: sen
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
On Mon, 28 Jun 1999, David S. Miller wrote:
>Date: Mon, 28 Jun 1999 06:12:44 -0400 (EDT)
>From: Alexander Viro
>
>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
Date:Mon, 28 Jun 1999 06:12:44 -0400 (EDT)
From: Alexander Viro
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
> > 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
> > 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 m
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in
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"
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 f
> 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, 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
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 t
> 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 i
> 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
> 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 id
> 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 ide
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.
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.c
:> 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
B
:> 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
Be
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
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 d
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
> > ...
> >
> >
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
> > ...
> >
> > n
:> [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 p
:> [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 pa
:
: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
:
: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 s
> -Original Message-
> From: Wes Peters [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 25 June, 1999 23:46
> To: Aaron Smith
> Cc: Alfred Perlstein; Brian F. Feldman; Karl Denninger;
> [EMAIL PROTECTED]
> Subject: Re: synch primitives (was Re: Microsoft performance)
>
>
> Here's a couple of
> -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
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
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 o
> :
> :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 de
1 - 100 of 109 matches
Mail list logo
