RW Date: Thu, 27 Nov 2003 11:24:23 -0500 (EST)
RW From: Robert Watson
[ CC list trimmed ]
RW The one thing that turns me off to this scheme is that I'd
RW like it if we could find a way to represent this using solely
RW existing BSD/UNIX kernel primitives (mmap, et al) and
RW userspace, rather
MD Date: Tue, 25 Nov 2003 11:50:25 -0800 (PST)
MD From: Matthew Dillon
MD (B) the authentication code access an IPC service which *ONLY* allows
MD challenge/response, does *NOT* give you direct access to the
MD encrypted contents of the password file, and which limits the challenge
MD
PW Date: Mon, 24 Nov 2003 18:56:21 -0800
PW From: Peter Wemm
PW We need nsswitch type functionality in /bin/sh. To the
PW people who want to make it static, lets see some static
PW binary dlopen() support or a nsswitch proxy system.
I started a new thread inquiring about the challenges
After watching the recent shared/dynamic threads, and reading the
archives from five or six years ago, I have a question...
Dynamic linking works by the kernel running the dynamic linker,
which loads shared objects and fixes the symbol tables, yes? Is
there some reason that a statically-linked
SL Date: Tue, 18 Nov 2003 17:06:06 -0700 (MST)
SL From: Scott Long
SL 3. Binary security updates: there is a lot of interest in providing a
SL binary update mechanism for doing security updates. Having a dynamic
SL root means that vulnerable libraries can be updated without having to
SL
GAD Date: Tue, 18 Nov 2003 21:54:53 -0500
GAD From: Garance A Drosihn
GAD Many freebsd users (me for one) are still living on a modem,
GAD where even one bump of 1.5 meg is a significant issue...
GAD
GAD Remember that the issue we're talking about is security
GAD updates, not full system
Any best guesses when -current will be destabilized for the SMPng
hackathon?
Eddy
---
Brotsman Dreger, Inc.
EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
Date: Wed, 18 Apr 2001 01:38:14 -0300 (BRST)
From: Rik van Riel [EMAIL PROTECTED]
Hence, my philosophy is that task switching and preemption are
necessary evils because hardware does not perfectly accomodate
software. If we must, we must... otherwise, use co-op switching as
the next
Date: Tue, 17 Apr 2001 14:52:06 -0700
From: Alfred Perlstein [EMAIL PROTECTED]
Disclaimer: I am not a kernel hacker.
The goal is to have a kernel that's able to have more concurrancy,
Right...
things like pre-emption and task switching on mutex collisions can
be examined and possibly
Date: Tue, 17 Apr 2001 22:18:34 + (GMT)
From: E.B. Dreger [EMAIL PROTECTED]
My instinct (whatever it's worth; remember my disclaimer) is that co-op
switching using something like tsleep() and wakeup_one() or similar would
be more efficient than trying to screw with mutexes.
Oops. I
Date: Tue, 17 Apr 2001 21:20:45 -0400
From: Bosko Milekic [EMAIL PROTECTED]
What happens if we get an interrupt, we're thinking about servicing
it, about to check whether we're already holding a mutex that may
potentially be used inside the mainline int routine, and another CPU
becomes
Date: Tue, 17 Apr 2001 19:06:08 -0700 (PDT)
From: Matt Dillon [EMAIL PROTECTED]
They don't have to be. If you have four NICs each one can be its own
interrupt, each with its own mutex. Thus all four can be taken in
parallel. I was under the impression that BSDI had achieved that
in
Date: Tue, 17 Apr 2001 19:34:56 -0700 (PDT)
From: Matt Dillon [EMAIL PROTECTED]
Yes. Also NICs usually have circular buffers for packets so, really,
only one cpu can be processing a particular NIC's packets at any given
moment.
We could always have a mutex for each NIC's ring buffer...
Date: Wed, 18 Apr 2001 00:04:12 -0300 (BRST)
From: Rik van Riel [EMAIL PROTECTED]
Not true. Interrupts work worse than polling because the interrupt
top halves can keep the CPU busy, whereas with polling you only
Top halves and _task switching_. Again, in a well-written handler with a
Going back to basic principles:
For minimal CPU utilization, it would be nice skip task switching, period.
Run something to completion, then go on to the next task. Poll without
ever using an interrupt.
The problem is that latency becomes totally unacceptable.
So now let's go to the other
15 matches
Mail list logo
