d. I can live with that for the moment, but this
feels weird to me (especially the difference of treatment between "-d
/dev" and "-d /etc/zfs"). FWIW I don't get this behavior on my other
hosts/NAS, however I use entire disks (wd(4)) for ZFS on these, not wedges.
Thanks!
--
Jean-Yves Migeon
jym@
https://www.NetBSD.org
narrowing this one down appreciated. Thanks :)
Cheers,
jym@
--
Jean-Yves Migeon
The NetBSD Foundation
http://www.NetBSD.org
he pool cache but not yet obtained
through the getter, they are still allocated but basically not used. It
would be interesting to see if the hit/miss ratio is affected for the
"pvpl" pool with your optimization.
--
Jean-Yves Migeon
Le 2016-03-14 13:40, Thor Lancelot Simon a écrit :
On Mon, Mar 14, 2016 at 12:10:29PM +0100, Jean-Yves Migeon wrote:
And same question applies if you reduce bs (128m from 1g for example)
I'll run the other test today or tomorrow -- this one's a "no" -- the
problem is jus
=/dev/rsd0g to /dev/null and dev/zero to ttcp (withou gzip),
simultaneously. Do you see any difference in the disk throughput when
stopping ttcp?
And same question applies if you reduce bs (128m from 1g for example)
--
Jean-Yves Migeon
Le 03/10/2015 18:19, Jean-Yves Migeon a écrit :
> Regarding the code, I am almost sure that the roundup2() is a
> requirement for microcode update for Intel x86 CPU. I suppose it
> requires a 16-byte aligned address for the blob hence the call to
> roundup2().
(answering to myself
er than
PAGE_SIZE).
Regarding the code, I am almost sure that the roundup2() is a
requirement for microcode update for Intel x86 CPU. I suppose it
requires a 16-byte aligned address for the blob hence the call to
roundup2().
--
Jean-Yves Migeon
location to store the requested
size (see the KMEM_SIZE option in [1] which is enabled under DIAGNOSTIC).
The only way I know of to guarantee alignement on a specific boundary is
through uvm_km_alloc or pool_cache.
[1] http://nxr.netbsd.org/xref/src/sys/kern/subr_kmem.c#63
--
Jean-Yves Migeon
Le 15/09/2015 23:17, Kamil Rytarowski a écrit :
> On 07.09.2015 17:58, Jean-Yves Migeon wrote:
>> Hello there,
>
>> Le 2015-09-07 12:24, Kamil Rytarowski a écrit :
>>> I'm here to get the support for it. At the moment it (cache nits)
>>> exceeds my compreh
at case I'd
prefer having the dev/inode indicated instead.
Cheers,
--
Jean-Yves Migeon
Le 13/06/2015 21:02, Jean-Yves Migeon a écrit :
Le 13/06/2015 19:30, Michael L. Hitch a écrit :
On Sat, 13 Jun 2015, Jean-Yves Migeon wrote:
I think that the slowness is I/O disk bound there: both disks were
used elsewhere first, so both have quite different block content.
Given that these
Le 13/06/2015 19:30, Michael L. Hitch a écrit :
On Sat, 13 Jun 2015, Jean-Yves Migeon wrote:
I think that the slowness is I/O disk bound there: both disks were
used elsewhere first, so both have quite different block content.
Given that these disks are rather slow (5400 RPM ones), I suppose
ster rebuild for the first minute or so.
Interesting. Thanks!
--
Jean-Yves Migeon
START queue
fifo 100
Tried swapping different disks, modifying the layout, or using SATA-only
and PATA-only disks, but it always ends up that way. Next on the list is
to test with -current, but I need to install radeon DRM firmwares first (:
Hints are, of course, appreciated.
Cheers,
--
Jean
macro)? It
emphasizes that the name should make sense, avoids confusion when
someone(TM) writes later a module called "hello" or "happy" (meh), and
also... helps spotting them out if they are erroneously loaded.
That and/or add a printf to each example in MODULE_CMD_INIT to warn
about this.
--
Jean-Yves Migeon
se by root?
- Enabling module autoload when a FreeBSD binary is called?
- Enabling syscalls? (Modules are loaded but all syscall return an error
otherwise)
--
Jean-Yves Migeon
Le 16/02/2015 02:50, David Holland a écrit :
On Mon, Feb 16, 2015 at 12:13:07AM +0100, Jean-Yves Migeon wrote:
> > > The funny thing is that a simple, *valid* call to sched_getparam()
> > > crashes the system. Clearly, it means that in 6 years, nobody
> > >
first (at least
for syscall related stuff) then squash it at a later time.
Cheers,
--
Jean-Yves Migeon
Le 09/11/2014 09:06, Maxime Villard a écrit :
Le 08/11/2014 23:28, Jean-Yves Migeon a écrit :
My suggestion was to enable the size setters/getters by default, and
possibly #ifdef part of the code that would be deemed unsuitable for
!diagnostic kernels.
Yes, but still, what's the poi
depends on caller's wishes.
--
Jean-Yves Migeon
Le 08/11/2014 19:43, Maxime Villard a écrit :
Le 08/11/2014 18:06, Jean-Yves Migeon a écrit :
I agree that the size not being tracked by the allocator (well, it is,
but the API is ill-designed in this regard) leads to great bugs.
Two things come to mind:
- I think that KMEM_SIZE should become
n. What does it mean to kmem_valloc(0,
KM_SLEEP)? A successful allocation but with an invalid pointer? Huh.
Cheers,
--
Jean-Yves Migeon
Le 02/02/2014 16:56, Taylor R Campbell a écrit :
Date: Sun, 02 Feb 2014 16:43:49 +0100
From: Jean-Yves Migeon
Even functions like calloc(3) are not required to check for the overflow
themselves when you pass them (number of elements, sizeof elements).
Overflow checks are
es when you pass them (number of elements, sizeof elements).
Overflow checks are rather cumbersome in C...
https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow
--
Jean-Yves Migeon
trigger this.
... nothing to see here, move right along. :-)
I though that the swapent was way bigger with the PATH_MAX component,
but it is about 4k, so... that makes for a whole lot of swap devices
indeed :)
--
Jean-Yves Migeon
* count", make the kmem_alloc(...)
succeed (the overflow will result in a small size_t if "count" is
properly chosen which is the size kmem_alloc() expects), then corrupt
adjacent kernel memory through the loop when writing into sep32 array.
Cheers,
--
Jean-Yves Migeon
better anyway. Just looking at the API is
enough :)
Cheers,
--
Jean-Yves Migeon
natives like
protocol buffers or thrift? Granted, those tools are meant for higher
level langages and RPCs, but if NetBSD managed to use XML in kernel, I
suppose those would fit too...
Cheers,
--
Jean-Yves Migeon
serland? NetBSD has traditionally tried to provide ongoing
binary
compatibility for almost all such APIs. If the Lua-related APIs
might
change in incompatible ways in the future, then this should be
explicitly documented.
I don't think Lua APIs are exposed at the syscall boundary.
Thanks!
--
Jean-Yves Migeon
Le 30/12/12 22:40, John Nemeth a écrit :
On May 22, 9:38am, Jean-Yves Migeon wrote:
Xen uses multiboot. Yet another thing on my todo list is to
handle boot time module loading in the multiboot case.
} As we have a decent module framework too, I would look at what module(7)
} offers when
t even
in src/, but without a clear goal/good design behind.
Happy new year's eve :)
[1]
http://nxr.netbsd.org/source/xref/src/sys/arch/xen/xen/xen_machdep.c#xen_parse_cmdline
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
llower() above). There are no codepath returns on
user/kernel boundaries in any of the code modified above.
Agreed.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
er than nothing though.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
with this.
I would suggest reading Antti's work about rump [1], rather than OSKit
(for which development has stopped years ago).
[1] http://www.netbsd.org/docs/rump/
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
om0 to the TCB, making this point
moot. But you can design an OS where dom0 is kept to a minimum (Qubes).
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
virtio driver, NetBSD writes at 25MB/s and
> without it only 7MB/s.
>
> However i noticed the inclusion of this driver was quite confidential
> since I haven't found it in the list of changes:
> http://www.netbsd.org/changes/changes-6.0.html
> Shouldn't it be here as well ?
> Sure that /kern is a prefix is not that nice, but I don't mind.
>
> What else beside firmware is in /libdata
Nothing more.
If we go for /kernel or /boot, could we move the kernel inside that
directory then? It will not make sense to have it remain under /netbsd
or /netbsd
t will raise confusion.
Technically modules are not libraries, but maybe /libdata/module is a
good option? We already have firmwares in /libdata/firmware, and those
get used by the kernel.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
st curious: what version of VMWare are you using, and is it with HVM
on an Intel or AMD box? I think we must investigate the context first
anyway, circumventing virtualization flaws with code quirks is not very
clean...
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On Mon, 4 Jun 2012 09:10:01 -0500, David Young wrote:
On Mon, Jun 04, 2012 at 10:34:06AM +0100, Jean-Yves Migeon wrote:
[General]
- Dumped pool_cache_invalidate_cpu() in favor of pool_cache_xcall()
which transfers CPU-bound objects back to the global pool.
- Adapt comments accordingly
On Thu, 31 May 2012 12:55:42 +0100, Jean-Yves Migeon wrote:
if my grepping is right pool_reclaim/pool_cache_reclaim are only
user
in subr_pool.c (for _HARDKERNEL) so draining should indeed only
happen
from the pageout daemon and not from interrupt context at all, so
we
should (if I'
for
-current though.
I will update both patches accordingly, but the drain start/end split
will likely remain for -6.
Thanks!
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On Tue, 29 May 2012 23:29:10 +0200, Lars Heidieker wrote:
On Tue, May 29, 2012 at 9:03 PM, Jean-Yves Migeon
wrote:
-current: I would like to take a more radical step and perform the
xcall(9) directly from pool_cache_invalidate(9). Given that xcall(9)
broadcasts cannot be sent from interrupt or
/msg017862.html
--
Jean-Yves Migeon
j...@netbsd.org
Index: sys/kern/subr_pool.c
===
RCS file: /cvsroot/src/sys/kern/subr_pool.c,v
retrieving revision 1.195
diff -u -p -r1.195 subr_pool.c
--- sys/kern/subr_pool.c5 May 2012 19:15:10
Le 01/05/12 04:18, Emmanuel Dreyfus a écrit :
Jean-Yves Migeon wrote:
The Linux API allows you to add arbitrary namespaces without a hitch.
You need to patch the kernel to do the same with the FreeBSD API.
Okay, but what API NetBSD will be using?
The Linux one. Nobody uses the FreeBSD API
Le 30/04/12 21:32, Emmanuel Dreyfus a écrit :
Jean-Yves Migeon wrote:
What came up from the Linux vs FreeBSD extended attributes conventions?
I can't remember if a clear path was chosen, and the archives do not
point to anything obvious (at least to me)
The Linux API allows you t
Le 30/04/12 19:53, Emmanuel Dreyfus a écrit :
Jean-Yves Migeon wrote:
What about backwards compat then? ENOATTR != ENODATA, so any code that
used ENOATTR will now break.
I remember reading that the attribute code was non-functional, and could
not be used. Are we sure that there is no other
d (ex: the added wedge overflows current
disk size), log it and let operator deal with it.
Of course, this does not replace integrity checks that can be performed
on the on-disk data (CRC, hash, rendundant info, ...). Such a feature is
orthogonal to wedges though.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
Le 30/04/12 16:43, Matthias Drochner a écrit :
On Sat, 28 Apr 2012 15:55:35 +0200
Jean-Yves Migeon wrote:
do you expect the checks to be performed in
userland, so anyone can be free to have overlaps/overflows, or let
the kernel do the checks and return errors using the size obtained
through
Le 30/04/12 15:57, Emmanuel Dreyfus a écrit :
Martin Husemann wrote:
I don't know - you could nuke ENOATTR from NetBSD and just make the kernel
return ENODATA.
I think this is the best way : ENOATTR does not seem to exist in any
standard. We only use it in extended attribute code, and there
Le 30/04/12 11:20, Emmanuel Dreyfus a écrit :
Hi
There is a choice to be made about returing ENOATTR or ENODATA when we
do not find an extended attribute.
Here are the existing behaviors:
1) return ENOATTR, while ENODATA is defined and has other usages: NetBSD
and MacOS X
2) return ENODATA,
Le 27/04/12 18:43, Matthias Drochner a écrit :
On Fri, 27 Apr 2012 01:02:46 +0200
Jean-Yves Migeon wrote:
Why push it to struct disk rather than letting backends handle it?
As the code looks now, the functions which scan disklabels
(sys/dev/dkwedge/dkwedge_*.c) get a "struct disk *&quo
Le 26/04/12 22:39, Matthias Drochner a écrit :
>
> I think it would be useful to add the total disk size to the common
> "struct disk". It could be used in wedge discovery to reject
> partitions which don't fit into the usable disk space.
>
> The reason I'm proposing this is that I just had a case
Le 22/12/11 18:00, Thor Lancelot Simon a écrit :
[snip]
Anyway, that's just one possible alternate approach. Working through it
makes me really wonder whether there's _any_ portable way to do this stuff.
But I wish we could have a public discussion about it before hacking up
public interfaces in
ormance
and security) [1]. So a peer review won't just be enough, you will also
have to test it extensively on your side too, and maybe ask core/port
maintainer approval.
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2793
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
phoronix-test-suite in pkgsrc, so if people are interested in
prototyping a performance-regression automation tool, contact me off-list).
Cheers,
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
sion. Propose a correct
alternative to this, so we can compare both implementations. The patch
shouldn't be that hard to pull out, now that
curtain/usermount/user_set_cpu_affinity do not pollute
suser/securelebel/bsd44 any more.
I prefer reading code with actual solutions than thoughts and words.
Nothing is perfect right from the beginning, I know that.
You saw our solution; let's see yours.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
el > 0)
- you end up implementing _all_ sysctl management inside
securelevel(9). So now, instead of exposing a fraction of the
securelevel internals to other secmodels, you expose other secmodels
internals to securelevel(9).
You cannot really end up with a clear separation of concerns here
ising
level). That implies that securelevel is present, but alas, anyone is
free not to use/load securelevel module. Hence, we have to provide a way
to cope with this: here comes secmodel_eval(9).
Hope this made everything more clear. Don't hesitate if you have more
questions.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
essary...
FLASK/Fluke? Now, if you like complexity...
But then again, I'm only pipe dreaming, and that's always easier than
implementing any of that, of course :)
Beware of dreams that can turn into nightmares :)
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
trols rights for superuser):
curtain/usermounts are not really a suser policy, rather an extension
from it. Hence the secmodel_extensions stuff.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
pcoming patch (with the
documentation) to restrict security.models settings when securelevel is
above 0.
Written by elad@, reviewed and tested (anita + basic rights tests) by
me. ok elad@.
Reviews before merge welcome. If nobody raises his voice, I'll proceed
to commit it at the end of
On Thu, 17 Nov 2011 23:08:28 -0600, David Young wrote:
On Fri, Nov 18, 2011 at 01:09:49AM +0100, Jean-Yves Migeon wrote:
- force all xcall(9) API consumers to pass dynamically allocated
arguments, a bit like workqueue(9) enqueues works. Scheduling
xcall(9) is now managed by a SIMPLEQ() of
On 18.11.2011 00:16, Mindaugas Rasiukevicius wrote:
Jean-Yves Migeon wrote:
On 25.09.2011 01:50, Jean-Yves Migeon wrote:
I would like to turn back on the xcall(9) block found in
pool_cache_invalidate(), now that rmind@ has implemented high priority
cross calls [1].
FWIW, I am still
On Wed, 9 Nov 2011 08:57:08 -0500, Thor Lancelot Simon wrote:
On Wed, Nov 09, 2011 at 11:49:10AM +0100, Jean-Yves Migeon wrote:
This is the idea. One shortcoming though: the pool_cache(9) content
is not synchronously invalidated, depleting the per-CPU cache would
only happen when the CPU
On Tue, 8 Nov 2011 22:53:09 -0500, Thor Lancelot Simon wrote:
On Wed, Nov 09, 2011 at 01:51:23AM +0100, Jean-Yves Migeon wrote:
1 # adding an "invalidate flag" to the pool cache, for each CPU.
How about a serial number, instead. Locally in each CPU's pool
cache,
globally
On 25.09.2011 01:50, Jean-Yves Migeon wrote:
I would like to turn back on the xcall(9) block found in
pool_cache_invalidate(), now that rmind@ has implemented high priority
cross calls [1].
FWIW, I am still struggling with this, without really having an idea on
how to fix this once and for
On Fri, 04 Nov 2011 01:39:45 +0100, Jean-Yves Migeon wrote:
(CCing tech-kern)
On 03.11.2011 10:38, Jean-Yves Migeon wrote:
On Wed, 2 Nov 2011 22:36:58 -0400, Thor Lancelot Simon wrote:
On Thu, Nov 03, 2011 at 03:30:54AM +0100, Jean-Yves Migeon wrote:
Should not? I took the same logic as the
(CCing tech-kern)
On 03.11.2011 10:38, Jean-Yves Migeon wrote:
On Wed, 2 Nov 2011 22:36:58 -0400, Thor Lancelot Simon wrote:
On Thu, Nov 03, 2011 at 03:30:54AM +0100, Jean-Yves Migeon wrote:
Should not? I took the same logic as the one allowing usermounts.
It's a matter of policy t
nd would be a dmover(9) like
system eventually reserving processor(s) for dedicated tasks, but I
guess that in this case the reserved cores would simply be made
unavailable in cpuctl(8)/pset(3)/etc...
What do you mean? A unified resource control API for kernel and
userland processes/LWPs?
rrent secmodel_suser(9) to allow this?
This issue comes regularly on various tech-* MLs, motivated by the fact
that people expect this behavior based on what they encounter on other OS.
--
Jean-Yves Migeon
j...@netbsd.org
Index: share/man/man9/secmodel_su
On 30.10.2011 06:18, Joerg Sonnenberger wrote:
On Sat, Oct 29, 2011 at 11:46:01PM +0200, Jean-Yves Migeon wrote:
When creating an IDLE kthread without having a CPU specified, the
actual code in kthread_create(9) will lead to a NULL deref [1].
IDLE as in idle loop? Why do you want to do that
ci->ci_schedstate.spc_lwplock);
+ } else {
+ if (ci != NULL)
+ lwp_unlock_to(l, ci->ci_schedstate.spc_lwplock);
+ else
+ lwp_unlock(l);
+ }
mutex_exit(proc0.p_lock);
/* All done! */
--
Jean-Yves Migeon
jea
#x27;t think so, unless you pass PR_LIMITFAIL and you hit pool's hard
limit.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
currently clarifying this API divergence with Manuel. We
should have something ready in a day or two. Stay tuned.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On 26.09.2011 00:21, Joerg Sonnenberger wrote:
On Sun, Sep 25, 2011 at 11:28:18PM +0200, Jean-Yves Migeon wrote:
On 25.09.2011 20:17, Joerg Sonnenberger wrote:
Just to practical notes:
(1) Please test that lint(1) is not stupid enough to bail out on it.
(2) Kill the !__STDC__ branches
nt could get affected by
them:
...
#ifndef DIAGNOSTIC
#define _DIAGASSERT(a) (void)0
#ifdef lint
#define KASSERTMSG(e, msg, ...) /* NOTHING */
#define KASSERT(e) /* NOTHING */
#else /* !lint */
..
So I am planning for the commit + rototill of all KASSERTMSG(...)
consumers t
On 25.09.2011 16:27, Joerg Sonnenberger wrote:
On Sun, Sep 25, 2011 at 04:02:04PM +0200, Jean-Yves Migeon wrote:
Unless someone objects (with arguments), I will commit this at the
end of the week and fix call sites to use the new macro;
KASSERTMSG() would then work like its man page suggests
On 17.09.2011 01:09, Jean-Yves Migeon wrote:
[snip]
Summary about my discussion regarding KASSERTMSG(): in its current form
it cannot append the msg passed as argument to it to the panic format
string, which makes it rather impractical: we fail to log the file,
line, expression that triggered
e losing a way to report the type of error
encountered in case there is one.
I would suggest to contact Manuel Bouyer directly, I think he is the one
that designed the API.
[1] http://nxr.netbsd.org/source/xref/src/common/lib/libprop/prop_kern.c#78
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
/bsdweb.cgi/src/sys/kern/subr_xcall.c#rev1.12
[2] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/subr_pool.c#rev1.176
[3] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/subr_pool.c#rev1.182
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On 25.09.2011 00:57, Christos Zoulas wrote:
On Sep 25, 12:40am, jeanyves.mig...@free.fr (Jean-Yves Migeon) wrote:
-- Subject: Re: MAXNAMLEN vs NAME_MAX
|> My vote is to bump without versioning, what's yours?
|
| Hmm, what do you want to do there? Increase NAME_MAX or decrease MAXNAMLE
s?
Hmm, what do you want to do there? Increase NAME_MAX or decrease MAXNAMLEN?
I would do the latter; ffs, ext2 and lfs all seem to use 255 for
MAXNAMLEN. So, I cast my vote for "bump without versioning".
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
, WQ_MPSAFE) != 0) {
aprint_error_dev(self, "failed to create workqueue\n");
goto bnx_attach_fail;
}
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On 08.09.2011 19:38, Joerg Sonnenberger wrote:
> On Thu, Sep 08, 2011 at 06:41:54PM +0200, Jean-Yves Migeon wrote:
>> On 08.09.2011 14:27, Joerg Sonnenberger wrote:
>>> There is no reason to allocate a string, just reserve e.g. 160 Bytes or
>>> so and use snprintf to
On Sun, 11 Sep 2011 20:53:55 -0400, Thor Lancelot Simon wrote:
On Sun, Sep 11, 2011 at 11:42:33PM +0200, Jean-Yves Migeon wrote:
On 11.09.2011 21:07, Thor Lancelot Simon wrote:
> Similarly, I am not sure I believe the security justification,
mostly
> because I don't really see w
any layers of indirection. Let's be honest,
running half a dozen Linux on a host is funny, you end up carrying
around your own datacenter.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On 08.09.2011 14:27, Joerg Sonnenberger wrote:
> On Thu, Sep 08, 2011 at 02:06:29PM +0200, Jean-Yves Migeon wrote:
>> I can't expect the kernel to be in a good shape when it calls panic(9)
>> so allocating/copying strings is not possible. So it has to be done at
>> c
not the real panic message:
"kernel %sassertion %s failed: file %s, line %d"
not very helpful.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
es for variable
argument lists: "msg" from KASSERTMSG(), and panic(9) itself. And I am
not aware of a solution where you can have two "..." in a C function.
Other possible solutions are either the ones that involve a more
"featureful" panic_verbose(9) function
SD only defines PGEX_{P,W,U,X}. Making the fault explicit in
traps.c will probably reveal the same kind of fault as the one Xen reports.
Now, as to why and how you can fix it: dunno.
[1] http://nxr.netbsd.org/xref/src/sys/arch/x86/include/pte.h#41
[2] http://nxr.netbsd.org/xref/src/sys/arch/amd64/amd64/trap.c#525
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
("e")
I find unpleasant to make one of them (the expression) appear explicitly
in a panic_verbose(...) prototype. panic() can be called for a whole lot
of reasons, where expression "e" does not necessarily carry a meaning.
Passing NULL when turning panic to its verbose form is proof
On 07.09.2011 17:02, Joerg Sonnenberger wrote:
> On Wed, Sep 07, 2011 at 04:54:05PM +0200, Jean-Yves Migeon wrote:
>> The attached patch takes care of this; it does not really "append" the
>> msg to the panic string (so it won't be available via panicstr like
>>
the panic string (so it won't be available via panicstr like
before), but now KASSERTMSG() will print the additional info.
Of course, an alternative is to fix the man page.
Opinions?
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
Index: sys/lib/libker
mers in
>> kernel).
>
> if it is in the kernel, it's strnlen(9) :-)
Right !)
Is there a way to know what functions are available from libkern, and
those only found in userland libs? Except by looking at libkern.h?
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On Wed, 31 Aug 2011 23:26:51 + (UTC), chris...@astron.com wrote:
In article <4e5ea673.8030...@free.fr>,
Jean-Yves Migeon wrote:
-=-=-=-=-=-
[strnlen in kernel]
Subject says it all. Anyone objects?
Looks fine to me. Don't forget to remove the duplicate copy from
src/lib/
Comments? If no-one objects, I'll commit this at the end of the week.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
Index: sys/lib/libkern/libkern.h
===
RCS file: /cvsroot/src/sys/lib/libkern/libkern.h,v
retrieving revision 1.98
#x27;t put a giant lock around xpq_queue. This doesn't make
any sense in a MP system, especially for operations that are frequently
called and still may take a while to complete. Just imagine: all CPUs
waiting for one to finish its TLB flush before they can edit their PD/PT
again... ouch.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
tain CPU here is very bad: for
example, with adequate time measurements you can obtain private RSA keys
when used for calculation.
[1] http://www.daemonology.net/papers/htt.pdf
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
kernel code and prefer to keep these in a small number of files; this
simplifies modularity as it avoids a complete kernel recompilation to
add/remove support for compat modules.
Thanks for reporting!
--
Jean-Yves Migeon
jeanyves.mig...@f
1 - 100 of 189 matches
Mail list logo
