On Tue, Jun 27, 2000, Cyrille Lefevre wrote:
> John Polstra wrote:
> > In article <[EMAIL PROTECTED]>,
> > Cyrille Lefevre <[EMAIL PROTECTED]> wrote:
> > >
> > > the problem I have, is that, when I run "cvs -t update -r RELENG_4",
> > > I got the following message (last 4 lines) :
> > [...]
> >
On Mon, 26 Jun 2000, Matthew Dillon wrote:
> This whole p vs curproc thing is a huge mess. 95% of the time
> p == curproc. The only places where it might not is in I/O ops
> that are completed by an interrupt or (in the case of NFS) some
> other process.
Any chances to
John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Cyrille Lefevre <[EMAIL PROTECTED]> wrote:
> >
> > the problem I have, is that, when I run "cvs -t update -r RELENG_4",
> > I got the following message (last 4 lines) :
> [...]
> > cvs update: notice: main loop with [EMAIL PROTECTED]:/cvsro
:>p is the process that made the syscall, curproc is the current
:> running process. You should be using p for the process that
:> called my_syscall.
:
:Since only one process can enter the kernel at a time (currently),
:and p is the process that made the system call, it is also the
:current
In article <[EMAIL PROTECTED]>,
Chris Costello <[EMAIL PROTECTED]> wrote:
> On Monday, June 26, 2000, Fox Anderson wrote:
> > What is the difference between p and curproc in my syscall?
> >
> > static int
> > my_syscall(struct proc *p, my_syscallargs *uap) {
> > curproc->..
> > }
On Mon, 26 Jun 2000, Mohana Krishna Penumetcha wrote:
> hi,
>
> HP-UX device driver reference manual says,
>
> "The side-effects of any write are not guaranteed to happen
> immediately. Writes are posted; they will complete eventually"
>
> to make sure all writes are flushed from the
Arun Sharma writes:
>
> For Intel processors, CPUID instruction spits out both L1 and L2 cache
> sizes. Perhaps, these things should be made a runtime option than a
> compile time option ?
That sounds like a good idea.
Also, I imagine that it would be possible to write a function to
emperi
In message <[EMAIL PROTECTED]> Cyrille Lefevre writes:
: # mv /path/to/symlink/ /other/location
: ^ note the terminating slash.
Read the terminating slash as "/." and it all should make sense.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-
preliminaries :
# mkdir -p /path/name /path/to
# touch /path/name/file
# ln -s /path/name /path/to/symlink
# mv /path/to/symlink/ /other/location
^ note the terminating slash.
move the target of the symlink instead of the symlink itself.
same results w/ rm -r and cp -r.
s
Alright, well that makes sense.. I guess it speeds things up some too? (I
had it enabled for a while, but didn't notice a difference).
=
| Kenneth Culver | FreeBSD: The best NT upgrade|
| Unix Systems Administrator
In message <[EMAIL PROTECTED]> Mohana Krishna
Penumetcha writes:
: HP-UX device driver reference manual says,
: "The side-effects of any write are not guaranteed to happen
: immediately. Writes are posted; they will complete eventually"
: to make sure all writes are flushed from the queue,
On Mon, Jun 26, 2000 at 12:50:41PM -0400, Kenneth Wayne Culver wrote:
> Just curious because I have no experience in this area... but what exactly
> does cache coloring get us... I've never actually gotten a really straight
> answer on this... Thanks
Read Curt Schimmel's book UNIX systems for mod
Just curious because I have no experience in this area... but what exactly
does cache coloring get us... I've never actually gotten a really straight
answer on this... Thanks
=
| Kenneth Culver | FreeBSD: The best NT up
[This message has also been posted.]
On Mon, 26 Jun 2000 10:42:35 +0100, Koster, K.J. <[EMAIL PROTECTED]> wrote:
> >
> > > > currently -> candidate
> > > > PQ_HUGECACHE PQ_CACHE1024
> > > > PQ_LARGECACHE PQ_CACHE512
> > > > PQ_MEDIUMCACHEPQ_CACHE256
> > > > PQ_NO
> And while I've got Jordan's attention -- did the last attempt at
> re-writing sysinstall generate any specification documents? If nothing
> else, they'd be useful content for the doc project. ]
No, this is one of the items on my TODO list which I really really really
have to get to soon
On Monday, June 26, 2000, Fox Anderson wrote:
> Hi all!
>
> What is the difference between p and curproc in my syscall?
>
> static int
> my_syscall(struct proc *p, my_syscallargs *uap) {
> curproc->..
> }
p is the process that made the syscall, curproc is the current
runnin
Hi all!
What is the difference between p and curproc in my syscall?
static int
my_syscall(struct proc *p, my_syscallargs *uap) {
curproc->..
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
My interest here was mainly to convey the fact that errno is not
automatically reset to 0. I agree that there should be no need to check it
if your system call succeeds. No arguments there. The original poster's
question, however, was inquiring about an automatic reset of errno. In
general, I'
On Mon, 26 Jun 2000, Rolandas Naujikas wrote:
>
> I would like to know more about current VFS and VM in FreeBSD kernel.
> Where I can get more details about that (from begginings).
A back issue of DaemonNews's 'Blueprints' column has an excellent article
explaining the VM system. http://www.dae
On 23-Jun-00 Nicole Harrington. wrote:
>> > Yeah.. This is why databases where invented :) Hey I
>> agree... However even if the html was databased.. (working on that
>> now) the custom graphics cannot be. (yet)
On Fri, 23 Jun 2000 13:12:48 +0930 (CST), "Daniel O'Connor" <[EMAIL PROTECTED]>
said
I would like to know more about current VFS and VM in FreeBSD kernel.
Where I can get more details about that (from begginings).
I'm requiring unionfs/nullfs to be working to use in jails.
I'm ready to give some time to make changes in implementation to be working.
roln ([EMAIL PROTECTED])
To
hi,
HP-UX device driver reference manual says,
"The side-effects of any write are not guaranteed to happen
immediately. Writes are posted; they will complete eventually"
to make sure all writes are flushed from the queue, it suggests to perform
a read operation.
i would like to know i
[ Going to -doc where it's pertinent, -hackers where it might find someone
who's prepared to do the work, and jkh for any expert commentary he
feels like tossing in.
And while I've got Jordan's attention -- did the last attempt at
re-writing sysinstall generate any specification documents
>
> > > currently -> candidate
> > > PQ_HUGECACHE PQ_CACHE1024
> > > PQ_LARGECACHE PQ_CACHE512
> > > PQ_MEDIUMCACHEPQ_CACHE256
> > > PQ_NORMALCACHEPQ_CACHE64
>
Hmm. At boot time, the BIOS displayes this square box with a lot of grub in
it that FreeBSD th
> I have an older 486 laptop which is newly running FreeBSD
> 4.0-RELEASE. When I attempted to enable APM and reboot, I got the
> following on my screen:
>
> --begin screen--
> Fatal trap 9: general protection fault while in kernel mode
> instruction pointer = 0x58:0x337
> stack pointer
> I notice that the /dev/smbX devices are exclusive access. This makes
> it impossible to run two (or more) programs concurrently that want
> to talk to SMbus devices (in my case, healthd and lmmon, both of which
> want to open /dev/smb0 to access the LM78).
>
> Is this an SMbus restriction, or a
26 matches
Mail list logo
