o N2L 3G1
Canada
-
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at j
erated by the underlying hardware, _and_ the hardware thresholds
can be updated to user-provided values. I think the sdtemp(4) driver
might be a better example of this.)
---------
| Paul Goyette | PGP DSS Key fingerprint: |
really correct? If (l == 0) then h is the warnmin value,
but if (l != 0) then h is warnmax and l is warnmin? That is very
strange indeed!
Enjoy your holiday, including tonight's "blue moon". :)
-
|
y for HEAD, but it should probably work on -5 if
some issues with sysmon_envsys(8) are also fixed. I've been trying to
get them all sorted out...
-
| Paul Goyette | PGP DSS Key fingerprint: | E-mail
ault in amd64.
Thanks,
Grégoire
-----
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731
system startup?
-----
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| K
and quotacheck both
take much longer.
HeHeHe - I don't run quotas, and except for my smallish root partition I
have WAPBL enabled everywhere to avoid the fsck time.
---------
| Paul Goyette | PGP DSS Key fingerprint:
ag = ia->ia_tag;
sc.sc_addr = ia->ia_addr;
If the firmware name is not a good indicator of the driver to use, the
"compatible" list can be used, via the generic iic_compat_match()
function.
I have tested this on a few sparc64 machines, it works for me.
I won't mind i
s fixed up shortly.
-----
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juni
On Thu, 4 Feb 2010, Paul Goyette wrote:
On Thu, 4 Feb 2010, Matthias Drochner wrote:
my laptop (running -current) now crashes as soon as the
battery reaches warning level.
This is due to a jump to NULL in sysmon_envsys_events.c,
line 891 - an indirect call to sme->sme_refresh.
This is indee
n't have
any battery-powered devices, I'll defer to Jukka to see what we can do.
-
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
|
30 sec!
All this needs a bit more thinking ...
---------
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 078
AC
adapter, of course, so we'll need to look into this as a separate
problem.
-
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | pa
ese checks.
Yeah, good point.
-----
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |
(Adding tech-kern@)
On Sat, 6 Feb 2010, Tobias Nygren wrote:
On Sat, 6 Feb 2010 20:12:32 +
Paul Goyette wrote:
Modified Files:
src/sys/arch/amd64/conf: GENERIC
src/sys/arch/i386/conf: ALL GENERIC
Log Message:
Add acpismbus enries - commented out!
If it builds it
custom config.
Done. Thanks!
-
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA
e for it to use!
-----
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
42759 is related to this and a rather simple patch - it needs to be
merged before debugging kern/42758 (so that the i2c is accessible on this
board).
PS: Please CC me, as I am not on this list.
-
| Paul Goyette | PGP DS
n the datasheet to see if there is
any mention of this?
-----
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engin
nable 2N3904 bipolar temp sensors. The default would be to keep
current behavior which expects a normal thermistor.
Now, I just need to figure out where the flags value gets passed into
the driver!
-----
| Paul Goyette | PGP
On Sun, 7 Feb 2010, Paul Goyette wrote:
In the wiki on lm-sensors.org I could find only one configuration which
actually uses the temperature sensors of the W83627HF. This configuration
also configures it to use the 3904 mode.
Yes, I went through the datasheet, too, and there seems to be no
For now, I'm inclined to do things according to the datasheet. :)
Unless anyone objects, I'll commit my patch later today. (And I'll add
comments on the flag value in all of the config files that contain the
lm(4) device.)
----
ncommented) if it compiles. :)
-----
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at junipe
dded to wbsio(4)?
-----
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
all my concerns. Let's give a couple days for others
to comment.
---------
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Net
it sysctl completely.
---------
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net
erties definitions.
Comments?
-----
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoy
n .Dx the" with
the proper OS name (Linux?)!
:)
---------
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer |
.
-
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer
quot;would be interested" list!
---------
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
p;langId=-1&storeId=500201
I tried to get Avnet to provide a quote on an eval board for an Octeon
and they never got back to me. (The eval board didn't have a Buy_Now
button, only a Request_Quote button.)
-----
the hardware/driver and the framework to the remembered
values.
I'd really appreciate comments/feedback/suggestions/etc.
---------
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Cus
into category A or B.
-
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyet
ut_ioctl() even work when the destination
is in kernel space? Or should I not be doing this?
Thanks in advance!
-----
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35
apm to scan for battery
sensors and A/C adapters?
-----
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786
.c to scan
the device list.
-----
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 773
ld be reloaded and unloaded whenever a new device is added.)
Is this something that would be useful?
-----
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | pa
ntion.
-----
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at junipe
On Thu, 20 May 2010, David Young wrote:
On Wed, May 19, 2010 at 08:52:52PM -0700, Paul Goyette wrote:
From the comments in the GENERIC config files, the primary reason
for omitting the various xxxVERBOSE options is to avoid including
large text tables in the resulting kernel. And I vaguely
nce unresolved?
Thanks in advance!
---------
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55D
kernel or loaded modules your module will simply not load.
This is actually what I was hoping would happen.
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at
No worries! When I finish up with PCI, I'll start in on USB.
---------
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network
he only thing I find that uses libpci is /usr/sbin/pcictl and that
seems to be working fine.
} No worries! When I finish up with PCI, I'll start in on USB.
I imagine that will be mostly copy/paste.
Mostly.
--------
g a full-tree search for libpci
shortly.
-----
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoy
On Sun, 23 May 2010, Martin Husemann wrote:
On Sat, May 22, 2010 at 08:29:22PM -0700, Paul Goyette wrote:
attempt to load from the filesystem. I expected it to fail, but the
failure mode is rather ungraceful
Maybe this would help?
Index: vfs_lookup.c
to be corresponding changes to many of the ad.* and md.* set lists
in src/distrib/sets/lists/modules/
I think this approach is "sub-optimal" and it's rather ugly; I expect
it will also lead to errors in future maintenance. But I don't have a
good alternative.
On Tue, 25 Ma
?
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
?
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org
l_register()/secmodel_deregister() by pushing these
calls into the mi_modcmd() calls inside the secmodules themselves.
This makes good sense to me. Assuming we can arrive at some sort of
concensus on this, I'll get working on it.
-----
here
development needs to recurse to to make the original task possible.
Thanks!
---------
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.co
On Wed, 16 Jun 2010, Antti Kantee wrote:
On Wed Jun 16 2010 at 04:13:54 -0700, Paul Goyette wrote:
With the current ways of secmodel register, I'd be damn careful to not
push it around. The effect is that if it's called 0 times, you have a
system which allows everything.
been explicitly unloaded. I think there is only one place in the code
where an entry is removed from the active list and moved back to the
builtin list.
---------
| Paul Goyette | PGP Key fingerprint: | E-mail addresses
current secmodel_register()
stuff.
-----
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |
On Wed, 16 Jun 2010, Antti Kantee wrote:
On Wed Jun 16 2010 at 06:31:59 -0700, Paul Goyette wrote:
The attached diffs add a new mod_disabled member to the module_t
structure, and set the value to false in each place that a new entry is
created. (Since all of the allocations of module_t
On Thu, 17 Jun 2010, Antti Kantee wrote:
On Wed Jun 16 2010 at 15:36:30 -0700, Paul Goyette wrote:
The attached diffs add one more routine, module_init3() which gets
called from init_main() right after module_class_init(MODULE_CLASS_ANY).
module_init3() walks the list of builtin modules that
ssue, so I get this committed and undo my breakage.
:)
---------
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel
t;Press any key to continue"
would be easier!)
Thanks in advance!
---------
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Netw
On Thu, 1 Jul 2010, Allen Briggs wrote:
On Thu, Jul 01, 2010 at 05:18:36AM -0700, Paul Goyette wrote:
a) a way to capture these messages in the normal message buffer for
later collection by syslog, or
b) a way to pause long enough to manually transcribe the output? (A
simple timed delay
ded
a new entry to the /boot.cfg on the other end:
menu=Serial/Single/Verbose/Debug:consdev com0; boot -svx
Then just boot, and things magically work!
Thanks for the clue-by-four
-----
| Paul Goyette | PGP Key f
ached.
-----
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| K
On Fri, 16 Jul 2010, David Young wrote:
On Fri, Jul 16, 2010 at 04:43:02PM -0700, Paul Goyette wrote:
Is there any reason anyone can think of to not add a NULL power
handler to the ipmi(4) driver? I can't see any reason for anything
special to happen either at suspend or resume, and the
Comments?
-----
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net
On Sat, 17 Jul 2010, Jukka Ruohonen wrote:
On Fri, Jul 16, 2010 at 06:14:39PM -0700, Paul Goyette wrote:
Would it be sufficient for ipmi(4) to refuse to suspend (return false
from the suspend method) if the watchdog is active?
Or should it make some sort of effort to disable the watchdog, and
nd handler if the wdog is present.
I'll add watchdog-factoring to my To-Do list, but for now I'll just
commit the changes for itesio(4) and ipmi(4).
-----
| Paul Goyette | PGP Key fingerprint: | E-mail ad
handler.
(We cannot use the usual handler com_resume() because it might attempt
to access registers which might not have been mapped!)
Any objection committing this?
-
| Paul Goyette | PGP Key fingerprint: | E-mail
s can
prevent a suspend if their timer is armed, but since swwdog is only a
pseudo-device it cannot register a pmf handler.
-----
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B
On Sun, 18 Jul 2010, Quentin Garnier wrote:
On Sun, Jul 18, 2010 at 07:14:57AM -0700, Paul Goyette wrote:
Currently, pseudo-devices are silently attached to the device tree
without giving the driver any access to the associated device_t
structure. As a result, the pseudo-device driver is
(Resent, this time with attachment!)
On Sun, 18 Jul 2010, Quentin Garnier wrote:
On Sun, Jul 18, 2010 at 07:14:57AM -0700, Paul Goyette wrote:
Currently, pseudo-devices are silently attached to the device tree
without giving the driver any access to the associated device_t
structure. As a
return false;
return true;
}
While you're there, I guess you could make swwdog_reboot a sysctl node.
Good point. Would this belong in the kern or machdep sysctl tree? I am
assuming it would be machdep.swwdog0.reboot for now, but it is easily
changed.
Revised dif
well change the value to
false.
Duh! Of course!
---------
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7
!!frobnitz".
Finally, on the eternal "someone should" astral plane, someone should
fix the kernel build to consist of building a set of modules and linking
them together, so we don't have more than one way to skin a kernel.
I'm pretty sure "someone" != "me" :
ices whose children are served by other modular drivers.
-----
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Ke
mutex_enter()
mutex_exit()
call A's init routine
mutex_enter()
mutex_exit()
---------
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
|
) another
module, then the lock is not dropped.
The lock is dropped only after the requested module and all of its
dependencies have been loaded and their xxx_modcmd() have been called.
-
| Paul Goyette | PGP Key fingerprint
On Mon, 26 Jul 2010, der Mouse wrote:
[moved from port-i386]
[me]
In passing, would it be appropriate and/or useful to suggest
improvements to [the envsys(4)] API? When I was writing code, I
found the envsys(4) ioctls to be deficient for my purposes.
[Paul Goyette]
I'd be interest
RC). If we can agree that it's desirable for one
module's xxx_modcmd() to load another module, then we can move to step 2
and figure out how to make it happen without breaking anything.
If we don't get consensus, then I'll most likely need to revert the
xxx_verbose modules.
where we have chunks of the system coming and going.
OK, I'm willing to make an attempt to implement the recursive_lock if
noone else wants to give it a try! It will probably take some time...
-----
| Paul Goyette
til I've had
some positive testing feedback, and hopefully some expert commentary on
the XXX. (Some additional "concensus" that this is the "right thing to
do" would also be appreciated!)
---------
| Paul Goy
ly need to have another copy of it in the rmutex_t
structure?
---------
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer |
le-test on additional architectures
B. Test to see that existing mutex operations still work correctly
C. Exercise the known use case if possible
D. Identify additional use cases
---------
| Paul Goyette | PGP Key fingerprint: | E
in mutex. That's why I didn't
allow them! :)
-----
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758
and noone in the rest of the kernel
would need to know about the lock.
-----
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
ly trivial, but
a couple of them should be looked at more closely in case I've missed
any subtleties in the original code:
kern/kern_syscall.c
net/if_ppp.c
-----
| Paul Goyette | PGP Key fingerprin
32.html
Good point. I think it's ok to do:
if (mutex_owned(mtx))
cnt++
else
lock
-----
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF
king for a mechanism that allows us to keep
this property while allowing modules to load other modules.
-----
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6
On Mon, 2 Aug 2010, Adam Hamsik wrote:
On Aug,Monday 2 2010, at 4:27 AM, Paul Goyette wrote:
On Sun, 1 Aug 2010, John Nemeth wrote:
I'm thinking the acquisition of module_lock should be pushed into
module_autoload() instead of having the caller acquire it for this very
reason. It
ubject line "Locking for module_autoload()"). Then it
will be nearly trivial to replace the current locking with your
suggested replacement.
On Mon, 2 Aug 2010, Adam Hamsik wrote:
On Aug,Sunday 1 2010, at 3:53 PM, Antti Kantee wrote:
On Sun Aug 01 2010 at 06:10:07 -0700, Paul Goyette
es, the cv mechanism, coupled with changing the semantics of
module_autoload() (to not require the caller to obtain the lock) makes
good sense here. I'm working on it and I should be able to post new
diffs tomorrow.
---------
On Mon, 2 Aug 2010, Paul Goyette wrote:
Yes, the cv mechanism, coupled with changing the semantics of
module_autoload() (to not require the caller to obtain the lock) makes good
sense here. I'm working on it and I should be able to post new diffs
tomorrow.
OK, it's time fo
mutex_owned().
this just does not match my actual experience in the kernel. i had
weird pmap-style problems and asserts firing wrongly while i did not
obey the rules in the manual directly.
.mrg.
-----
| Paul Goyette
t the module_autoload() changes separately.
Will do. I will commit the changes to sys/kern/kern_module.c,
sys/sys/module.h, and share/man/man9/module.9 separately from the
other changes.
-----
| Paul Goyette | PG
On Mon, 2 Aug 2010, Paul Goyette wrote:
On Tue, 3 Aug 2010, matthew green wrote:
i think this looks good enough. wait for some others eyes, though.
No hurry. I'm going to try to add a new atf test case for the recursive load
case, and it will take some time for me to come up to spe
tex_owned" in ways that
would appear to violate our own documentation. And it also addresses
eeh's (and mrg's) concerns of keeping the lock across potentially
long-duration operations.
-----
| Paul Goyette
blem.
3. Since we're still technically abusing the mutex(9) man-page caveat
about using mutex_owned() for making locking decisions, it would
be very much appreciated (at least by myself) to have an explanation
of WHY it is OK in this case to do it here, but not somewhere else.
OK, got it.
I'll have another set of patches in a few days.
On Thu, 5 Aug 2010, Andrew Doran wrote:
On Wed, Aug 04, 2010 at 10:28:56AM -0700, Paul Goyette wrote:
On Wed, 4 Aug 2010, Andrew Doran wrote:
Sorry for not replying sooner.
Please don't add a generic recursive lock fa
On Thu, 5 Aug 2010, Paul Goyette wrote:
Attached is the latest version of this change. For simplicity, I have broken
the patches up into five separate groups:
Part 1 defines a set of new kernel locking primitives in file
kern/kern_lock.c to implement the recursive kernconfig_mutex. (I'
On Thu, 5 Aug 2010, Paul Goyette wrote:
OK, got it.
I'll have another set of patches in a few days.
Well, it was a slow day at the office today, so I found some time to
work on this! :)
Attached is the latest version of this change. For simplicity, I have
broken the patches up
On Fri, 6 Aug 2010, Mindaugas Rasiukevicius wrote:
Hello,
Paul Goyette wrote:
Well, it was a slow day at the office today, so I found some time to
work on this! :)
Attached is the latest version of this change. For simplicity, I have
broken the patches up into five separate groups
On Thu, 5 Aug 2010, Paul Goyette wrote:
On Thu, 5 Aug 2010, Paul Goyette wrote:
OK, got it.
I'll have another set of patches in a few days.
Well, it was a slow day at the office today, so I found some time to work on
this! :)
Attached is the latest version of this change.
On Sun, 8 Aug 2010, Mindaugas Rasiukevicius wrote:
Paul Goyette wrote:
Following up on all the various comments from jmcneil@, pooka@, and
rmind@, I've attached a revised set of diffs. The most significant
change between this and the previous revision is the separation o
1 - 100 of 654 matches
Mail list logo
