(Sorry, I forgot to add in my last message that I am not subscribed to
this list, so please cc me in replies.)
Date: Sun, 10 Jul 2011 21:57:03 +0300
From: Alexey Cheusov cheu...@tut.by
As I said earlier my code is based solely on kauth(9) and I assume
it is correct. Also I assume my
(I am not subscribed to this list, so please cc me in replies.)
Rename is still broken in a number of file systems because of races
and deadlocks and an insane locking protocol. To make it easier to
fix them, and to make it easier to replace the VOP_RENAME protocol by
something less insane in
sys_close guarantees that it has closed the file descriptor when it
returns, even if it returns EINTR. Thus, repeating a call to close(2)
when it returns EINTR is always a mistake on NetBSD, and on other
systems as well such as FreeBSD and Linux. (This conforms to POSIX,
as would an
On ufs (and tmpfs and perhaps others), reading from or writing to a
fifo updates its [acm]time -- even on read-only file systems (although
in that case the changes are not written to disk). It's been this way
since r1.1 of ufs_vnops.c.
Why? Conceptually, what is actually read from the fifo
Date: Mon, 26 Dec 2011 18:35:34 +
From: Mouse mo...@rodents-montreal.org
Is one inode update per minute enough to be a significant issue?
It means the disk must continue spinning and, e.g., will continue to
draw power from a laptop battery to do so, even when the system is
Date: Thu, 29 Dec 2011 06:20:36 +0100
From: m...@netbsd.org (Emmanuel Dreyfus)
I can reliabily crash latest netbsd-5 kernel with an unprivilegied
ktrace -p on an unexisting process...
What prevents ktrace_common from returning -- and sys_ktrace from
subsequently fd_aborting the file
Rename is the hairiest vop and has the insanest API of them all, and
in most of our file systems it's hosed. I'd like to fix that.
A few months ago I asked here for review on a patch to implement a
generic abstraction with a saner protocol for implementing rename, and
to make several file
Date: Thu, 7 Jun 2012 16:39:50 -0400
From: Thor Lancelot Simon t...@panix.com
On Thu, Jun 07, 2012 at 07:06:04PM +, Michael van Elst wrote:
But that also means that you cannot copy an encrypted image to
a disk with different geometry. Someone has decide wether that's
Date: Tue, 17 Jul 2012 18:55:17 +0100
From: Mindaugas Rasiukevicius rm...@netbsd.org
David Holland dholland-t...@netbsd.org wrote:
Creating CVS branches does not help with this sort of thing; it just
makes development slower. It also makes it less likely that the
changes will
Date: Fri, 5 Oct 2012 18:12:54 +0100
From: David Laight da...@l8s.co.uk
On Fri, Oct 05, 2012 at 04:16:38PM +, David Holland wrote:
Getting AIO working natively first would be a good step. :(
How does Linux handle aio?
...
Some OS (noteably RSX/11M and windows) always do
I'm working on fixing ZFS locking, and I ran into a diference between
NetBSD's and Solaris's interpretation of condvars.
In Solaris, it seems to be kosher to do
cv_broadcast(cv);
cv_destroy(cv);
at least if waiters use only cv_wait and not cv_wait_sig c. That
idiom makes NetBSD very
Date: Sun, 14 Oct 2012 09:37:09 +0200
From: Martin Husemann mar...@duskware.de
In the zfs code, where do they store the mutex needed for cv_wait?
In the two cases I have come across, dirent locks and range locks, a
number of condvars, one per dirent or one per range, share a common
Date: Sun, 14 Oct 2012 10:04:53 +0100
From: David Laight da...@l8s.co.uk
Hmmm IIRC solaris kernel cv_init() is actually a malloc, so cv_destroy()
is a free() - and thus mandatory.
OTOH doesn't NetBSD's cv_init() just initialise the memory, making
cv_destroy() not strictly
Date: Sun, 14 Oct 2012 14:27:48 +
From: Taylor R Campbell campbell+netbsd-tech-k...@mumble.net
In the two cases I have come across, dirent locks and range locks, a
number of condvars, one per dirent or one per range, share a common
mutex in some common enclosing object
Date: Sun, 04 Nov 2012 11:45:15 +0100
From: Jan Danielsson jan.m.daniels...@gmail.com
When I think back, I recall noticing that I got brutally high
throughput during the transfer; which raises the question: Is there any
known heavy load bug lurking which causes the postgresql
Date: Fri, 09 Nov 2012 18:53:45 -0500
From: Greg Troxel g...@ir.bbn.com
FWIW, I agree with the notion that defaults should be at a path that is
~always in root; it's normal to have /var in a separate fileystem (at
least for old-school UNIX types; I realize the kids these days think
Date: Sat, 10 Nov 2012 07:44:18 +0100
From: m...@netbsd.org (Emmanuel Dreyfus)
This patch implementes openat(2), mkdirat(2), mknodat(2), mkfifoat(2)
fchmodat(2) and fchownat(2), and adds test cases for the new system
calls:
I know this is a bike shed, and I'm sorry to be the one
Some quick responses to the substance of the patch now that I have
skimmed it...
Date: Sat, 10 Nov 2012 07:44:18 +0100
From: m...@netbsd.org (Emmanuel Dreyfus)
Index: sys/sys/namei.h
+int nameiat_simple_kernel(int, const char *, namei_simple_flags_t,
+struct vnode **);
Date: Sun, 11 Nov 2012 08:31:02 +0100
From: m...@netbsd.org (Emmanuel Dreyfus)
Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote:
I don't think namei.h / vfs_lookup.c is the right place to be handling
file descriptors. Can you make these take vnodes, rather than file
Date: Sun, 11 Nov 2012 05:55:23 +0100
From: m...@netbsd.org (Emmanuel Dreyfus)
Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote:
+ /*
+ * openat() falls back to open() behavior if
+ * - path is absolute XXX check this.
+ * - fd is AT_FDCWD
Date: Tue, 13 Nov 2012 09:52:21 +
From: Emmanuel Dreyfus m...@netbsd.org
New version of the patch for POSIX extended API set 2:
http://ftp.espci.fr/shadow/manu/openat3.patch
OK, thanks, this looks better. Some comments below, mostly very
minor. First, though -- are there any
Date: Thu, 15 Nov 2012 11:03:15 -0500
From: Thor Lancelot Simon t...@panix.com
On Thu, Nov 15, 2012 at 11:12:09AM +, Emmanuel Dreyfus wrote:
Hi
Here is a patch that implements fexecve(2) for review:
http://ftp.espci.fr/shadow/manu/fexecve.patch
This strikes me as
Date: Thu, 6 Dec 2012 08:23:07 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
Looks like this thread is dead. No one beside David Holland is
interested and David objects. I take back my proposal.
I'm interested, but I haven't fit enough of the vnode life cycle or
the fstrans
When pool_get can't service the request from any pooled storage
because it's all in use, it calls out to the pool's allocator.
Sometimes the pool's allocator can't service the request, e.g. because
it has to come from kva and kva is currently too scarce or fragmented
to find space. In this case,
I'd like to add a member fo_mmap to struct fileops so that cloning
devices can support mmap and use other kinds of uvm objects than just
uvm_deviceops and uvm_vnodeops.
Currently the only ways to customize mmap(2) are
. with a device node, by setting d_mmap in the struct cdevsw, but the
I'd like to add/change the following utilities for pointers and
arithmetic. Here is the summary of definitions I'm proposing;
detailed rationale follows below. Comments?
#define roundup2(x, m) (((x) + ((m) - 1)) ~((m) - 1 + ((x) - (x
#define rounddown2(x,m) ((x) ~((m) - 1 + ((x) +
Urk...sorry to self-reply, but ten-fingered copypasta invariably
tastes wrong. Let's try asking the computer to make copypasta for me
from the code that I actually tested:
/* typeof-free roundup2/rounddown2 */
#define roundup2(x, m) (((x) + ((m) - 1)) ~((m) - 1 + ((x) - (x
#define
Date: Thu, 21 Mar 2013 18:42:16 +
From: Taylor R Campbell riastr...@netbsd.org
/* typeof-free roundup2/rounddown2 */
#define roundup2(x, m) (((x) + ((m) - 1)) ~((m) - 1 + ((x) - (x
#define rounddown2(x,m) ((x) ~((m) - 1 + ((x) - (x
/* multiple
Date: Thu, 21 Mar 2013 21:11:56 +0100
From: Rhialto rhia...@falu.nl
I would argue that all such mumble() should really be changed to
int
mumble(struct foo *foo)
{
struct bar *bar = foo-f_bar;
...
}
Date: Sat, 20 Apr 2013 23:47:59 +0200 (CEST)
From: iMil i...@home.imil.net
My question is: how will tmpfs behave? If I mount the WRKOBJDIR
without any argument, it will use, if I understand correctly
the manpage, all of the available memory. Does this mean I will
end up in a
I'm trying to understand how transactions, suspension, and snapshots
fit together in vfs and fss, and the man pages seem a little too
disjointed for me to figure it out. Is there any high-level overview
of how all these things fit together?
Only a few kernel configurations have options VND_COMPRESSION enabled
by default -- i386/GENERIC and a few evbarm kernels, mainly. Any
reason we don't have it enabled in many others, e.g. amd64/GENERIC?
I haven't hammered on vnd(4) with compressed images, but it seems to
work in light testing.
Date: Tue, 18 Jun 2013 05:11:48 +
From: Taylor R Campbell riastr...@netbsd.org
Some discussion with rmind@ today revealed a (highly unlikely) race
that could cause a read from /dev/random to hang indefinitely even
though entropy is available. Attached is an updated patch
d7128d19ac533ae5b00b58477b6f975708a4b192
Author: Taylor R Campbell riastr...@netbsd.org
Date: Sun Jun 23 15:39:36 2013 +
Fix races in /dev/u?random initialization and accounting.
- Push /dev/random `information-theoretic' accounting into cprng(9).
- Use percpu(9) for the per-CPU
Date: Mon, 26 Aug 2013 11:57:28 +0200
From: Martin Husemann mar...@duskware.de
Unfortunately this change prevents my system from booting - nothing happens
after mounting root:
root on sd0a dumps on sd0b
root file system type: ffs
and that's it - sits there idle.
Also
Date: Wed, 09 Oct 2013 11:08:51 +0200
From: Marc Balmer m...@msys.ch
I found out that several programs already have Lua bindings, but for
unknown reasons that code is not enabled by default, which is kind of
weird given that the Lua library is in base... So we have Lua bindings
Date: Mon, 14 Oct 2013 22:46:53 +0200
From: Marc Balmer m...@msys.ch
It is entirely plausible to me that we could benefit from using Lua in
base, or sysinst, or maybe even in the kernel. But that argument must
be made by showing evidence of real, working code that has
Date: Thu, 17 Oct 2013 19:16:16 -0300
From: Lourival Vieira Neto lourival.n...@gmail.com
Lua is a tool, not an end in itself. I think that you are formulating
a chicken-and-egg problem: we need the basic support for then having
applications, and we need applications for then having
Date: Fri, 18 Oct 2013 18:12:29 -0300
From: Lourival Vieira Neto lourival.n...@gmail.com
On Fri, Oct 18, 2013 at 9:08 AM, Taylor R Campbell riastr...@netbsd.org
wrote:
[*] You could do this in a branch, you could do this in a private Git
repository, or you could even just do
Date: Sat, 19 Oct 2013 09:47:14 +0200
From: Marc Balmer m...@msys.ch
And now to give you a practical example what I personally do with lua(4)
right now: In the past I wrote several tty line disciplines to decode
various serial formats. Now I have a need for that again. Doing
Date: Fri, 1 Nov 2013 16:47:35 +
From: David Holland dholland-t...@netbsd.org
rmind@ points out that it's possible to create zero-length symlinks.
As zero-length symlinks aren't sensible, this should probably be
prohibited. Does anyone see any reason they shouldn't be?
Some
Date: Mon, 30 Dec 2013 11:35:48 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
The layered file systems hashlists currently have to work on locked
vnodes as the vnode operations returning vnodes return them locked.
This leads to some very dirty hacks -- see
Date: Mon, 13 Jan 2014 16:06:02 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
On Jan 13, 2014, at 8:39 AM, David Holland dholland-t...@netbsd.org wrote:
On Tue, Jan 07, 2014 at 11:30:40AM +0100, J. Hannken-Illjes wrote:
(also, while this is minor I think I'd rather have
Date: Wed, 15 Jan 2014 16:08:04 +
From: Taylor R Campbell campbell+netbsd-tech-k...@mumble.net
As is, existing code calling, e.g., VOP_MKDIR will still compile. Is
there a reason the versioning doesn't rename it to VOP_MKDIR_V2?
For that matter, why new machinery
Date: Thu, 16 Jan 2014 07:07:56 +
From: David Holland dholland-t...@netbsd.org
On Wed, Jan 15, 2014 at 04:31:07PM +0100, J. Hannken-Illjes wrote:
I put a diff to http://www.netbsd.org/~hannken/vnode-pass2a-3.diff that
changes the vnode creation operations to keep the dvp
Date: Thu, 16 Jan 2014 15:13:47 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
Taylor, you're right.
- the change to zfs_ioctl.c was wrong and unneeded (this part is not
used from NetBSD).
- the change to zfs_replay.c was wrong. Looks like zfs_zget() returns
a
Date: Mon, 20 Jan 2014 16:01:07 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
Back to vnode creation operations returning unlocked vnodes I put a new
diff to http://www.netbsd.org/~hannken/vnode-pass2a-4.diff
Any more objections or OK to commit?
On further consideration,
Date: Mon, 27 Jan 2014 13:05:58 -0600
From: Frank Zerangue frank.zeran...@gmail.com
I looked at hifn, amdpm, and bcm28335 RNG drivers and they all seem
to do the same. They setup a callout to periodically call there RNG
reader to prime the random pool with more bits; but I don't
If I have a module that needs to run some code to set up some data
structures before I can configure a device, I would like to use code
that looks like the following. This works for modules compiled
separately, but for builtin modules, it doesn't, because the kernel
runs configure long before it
Date: Mon, 03 Feb 2014 00:37:34 +1100
from: matthew green m...@eterna.com.au
+sep = kmem_alloc(sizeof(*sep) * count, KM_SLEEP);
+sep32 = kmem_alloc(sizeof(*sep32) * count, KM_SLEEP);
You can overflow sizeof(*sep) * count, make the kmem_alloc(...)
Date: Sun, 02 Feb 2014 16:43:49 +0100
From: Jean-Yves Migeon jeanyves.mig...@free.fr
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 rather cumbersome in C...
Date: Mon, 3 Feb 2014 12:04:27 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
As announced some weeks ago here comes the API change to VOP_LOOKUP:
Change vnode operation lookup to return the resulting vnode *vpp locked.
Change cache_lookup() to return an unlocked vnode.
Date: Mon, 3 Feb 2014 12:04:27 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
As announced some weeks ago here comes the API change to VOP_LOOKUP:
Change vnode operation lookup to return the resulting vnode *vpp locked.
Change cache_lookup() to return an unlocked vnode.
Date: Thu, 6 Feb 2014 17:16:18 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
On Feb 6, 2014, at 4:52 PM, Taylor R Campbell
campbell+netbsd-tech-k...@mumble.net wrote:
One more question: Are you planning to change relookup to return the
result unlocked, too
Date: Fri, 21 Feb 2014 12:35:40 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
Diff available at http://www.netbsd.org/~hannken/vnode-pass3-1.diff
Comments or objections anyone?
This seems needlessly complicated to me. Outside of the vfs lifecycle
code, why would you ever
Date: Sun, 23 Feb 2014 13:57:52 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
Currently dead vnodes still reside on the vnodelist of the file system
they have been removed from. To me it looks much better to create
a dead mount that takes dead vnodes until they get freed.
Date: Tue, 25 Feb 2014 15:11:04 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
I'm quite sure we cannot kill ALL instances of LK_RETRY as
OK, perhaps not yet. But:
- at least union file system needs the unlock / relock when looking
up DOTDOT and the relock has to
Prompted by hannken's recent patch to tweak vnode locking, and because
I couldn't figure out what in Cthulhu's name is going on in the mess
that is the vnode life cycle for the umpteenth time I looked at it, I
wrote a draft (attached) of a new vnode life cycle that sorts out all
of the issues I
Date: Fri, 28 Feb 2014 15:02:41 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
On Feb 27, 2014, at 7:16 PM, Taylor R Campbell
campbell+netbsd-tech-k...@mumble.net wrote:
I'm currently short on time but here are some comments and remarks.
Thanks!
First, using an explicit
Date: Fri, 28 Feb 2014 17:22:11 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
On Feb 28, 2014, at 4:41 PM, Taylor R Campbell
campbell+netbsd-tech-k...@mumble.net wrote:
Actually, I think I may want to change that, so that vget can be done
under a pserialized read -- i.e
Date: Mon, 3 Mar 2014 11:11:04 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
Add an interface to iterate over a vnode list:
void vfs_vnode_iterator_init(struct mount *mp, void **marker)
void vfs_vnode_iterator_destroy(void *marker)
bool
Date: Mon, 3 Mar 2014 15:55:16 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
On Mar 3, 2014, at 3:28 PM, Taylor R Campbell
campbell+netbsd-tech-k...@mumble.net wrote:
/* mount.h */
struct vnode_iterator; /* opaque */
void vfs_vnode_iterator_init(struct mount
Date: Mon, 3 Mar 2014 16:19:40 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
On Mar 3, 2014, at 4:11 PM, Taylor R Campbell
campbell+netbsd-tech-k...@mumble.net wrote:
That is exactly what I was going for, except with a typed pointer
instead of a void pointer.
Please
Date: Mon, 3 Mar 2014 17:20:43 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
New diff at http://www.netbsd.org/~hannken/vnode-pass4-3.diff
Looks good to me now, assuming all tests pass with it. (Do we have
any automatic tests for ffs_reload c.?)
The lfs changes look suspect --
Date: Fri, 14 Mar 2014 14:40:50 + (UTC)
From: chris...@astron.com (Christos Zoulas)
In article 20140314143532.ga17...@britannica.bec.de,
Joerg Sonnenberger jo...@britannica.bec.de wrote:
Actually, it would simplify things a lot if /dev/ptmx was a symlink to
/dev/pts/ptmx.
Date: Fri, 21 Mar 2014 11:10:54 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
The vnode flags VI_CLEAN and VI_XLOCK are used in file systems to
check for reclaimed or reclaiming but still active vnodes, so
make the vnode flags VI_XLOCK, VI_CLEAN (and VI_LOCKSHARE) private
Date: Sun, 6 Apr 2014 12:14:24 +0200
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
Currently all file systems have to implement their own cache of
vnode / fs node pairs. Most file systems use a copy and pasted
version of ufs_ihash.
So add a global vnode cache with lookup and
Date: Mon, 7 Apr 2014 15:51:00 +0200
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
On 07 Apr 2014, at 03:22, Taylor R Campbell
campbell+netbsd-tech-k...@mumble.net wrote:
Is the plan to nix getnewvnode and ungetnewvnode? It would be good to
avoid long-term duplication of its
Date: Mon, 7 Apr 2014 16:44:47 +0100
From: Mindaugas Rasiukevicius rm...@netbsd.org
One concern though: can you benchmark ./build.sh on a machine with 8 or
more CPUs? I fear that vcache.lock might be a bit contended and we ought
to figure out how much. If the contention is not
Date: Mon, 7 Apr 2014 17:27:01 +0100
From: Mindaugas Rasiukevicius rm...@netbsd.org
Should be fine, but once tmpfs is switched to use vcache, it might become
a little bit more visible for some workloads..
Why switch tmpfs to use vcache? That would add memory and time
overhead for no
Date: Mon, 7 Apr 2014 18:32:02 +0200
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
On 07 Apr 2014, at 18:02, Taylor R Campbell
campbell+netbsd-tech-k...@mumble.net wrote:
In that case, could you set the VI_CHANGING bit in vp, rather than
node-vn_vnode = NULL in the vcache
Date: Wed, 9 Apr 2014 11:10:37 +0200
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
There is no need to do this VI_CHANGING etc. here. Primary goal of
the vnode cache is to always initialise vnode / fs node pairs before
they become visible or appear on any lists.
But the
Date: Tue, 8 Apr 2014 00:25:32 -0400
From: Thor Lancelot Simon t...@panix.com
Attached are the changes from the tls-earlyentropy branch, which tries
to make the output of /dev/random less predictable -- particularly for
an attacker outside the box -- earlier.
I intend to merge
Date: Mon, 14 Apr 2014 15:58:28 +0200
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
Also replaced the cv_wait/cv_broadcast with kpause as insert collisions
are very rare and moved the common vnode initialisation to vnalloc.
New diff at
Repeating what I said privately for the public record:
The changes to cprng.h expose a lot of guts of the new cprng_fast
implementation. I don't see justification for this. As I understand
it, the goals of rewriting cprng_fast are:
1. Replace the unsafe arc4random by a safer algorithm.
2.
Closer inspection of HC-128 reveals that it uses secret-dependent
array indices[*], so for that reason alone I don't think we should
adopt it. It also has a very large state, which is going to hurt the
cache on big systems and hurt the stack on little systems.
So, could you please split your
Date: Fri, 18 Apr 2014 12:38:38 -0400
From: Thor Lancelot Simon t...@panix.com
3) If the algorithm's use of state-dependent array indices
presents a real weakness in practice, why aren't there any
published results on this and why was it chosen as, and
Date: Fri, 18 Apr 2014 19:58:06 +0200
From: Markku-Juhani Olavi Saarinen m...@iki.fi
If you want to get rid of RC4, use AES in CTR mode. It is standard,
compact, clean, and really fast solution. May sound boring, but gives
me a feel of solid security engineering.
We use that for
Date: Fri, 18 Apr 2014 21:50:46 -0400
From: Thor Lancelot Simon t...@panix.com
Are there actually any callers of cprng_fast at IPL_HIGH? Are there
actually any legitimate random decisions to be made at IPL_HIGH? I'm
sceptical.
What do you get if you cross an elephant and a
Date: Fri, 18 Apr 2014 16:12:32 -0400
From: Thor Lancelot Simon t...@panix.com
With those observations in mind, I offer these design criteria for
cprng_fast():
Strength criterion: At the time of the selection of an algorithm
for
Date: Sun, 20 Apr 2014 03:18:03 -0400
From: Thor Lancelot Simon t...@panix.com
The following tests were run:
1) Cycles-per-byte, 32 bit request: at initial keying of
the generator and each automatic rekeying.
2)
Sorry, I need to focus my time on other things at the moment, so I'll
stop getting in the way of progress -- I withdraw my objection. I
still think we should not have two different code paths for creating
vnodes, and it would be nice to reduce the overhead, but we can sort
that out later.
By the
Date: Fri, 9 May 2014 19:01:04 -0400
From: Matthew Mondor mm_li...@pulsar-zone.net
Is it expected in vcache_common() for the interlock to remain held even
if returning an error?
vget unconditionally drops the interlock, so it will never remain
held, error or not.
Date: Sat, 10 May 2014 21:42:59 +0200
From: Thomas Schmitt scdbac...@gmx.net
Is there a tutorial Localhost NFS for Dummies ?
Just set up /etc/exports (see `man exports') and get rpcbind, mountd,
and nfsd running:
/etc/rc.d/rpcbind onestart
/etc/rc.d/mountd onestart
/etc/rc.d/nfsd
Date: Tue, 13 May 2014 22:01:20 +0200
From: Thomas Schmitt scdbac...@gmx.net
grep on the source tree :-)
Did not bring any more findings, except 9 directory loops.
The open risk is that some application like makefs might rely
on these headers ... /usr/src/usr.sbin/makefs says
DRM/GEM uses uvm_aobj for long-term pageable graphics buffers, but
when these buffers are assigned physical pages whose addresses can be
programmed into the GPU's page tables, only certain physical pages are
allowed -- specifically, Intel GPUs can handle only 32-bit, 36-bit, or
40-bit physical
Date: Tue, 20 May 2014 13:54:44 -0700
From: Matt Thomas m...@3am-software.com
Wrong approach. These should be on dedicated vm freelists instead.
Look at how mips64 has first512m, first4g, etc. You could have
first4g, first64g, first1t. Then you can use UVM_PGA_STRAT_ONLY.
How
Date: Thu, 22 May 2014 16:47:10 + (UTC)
From: chris...@astron.com (Christos Zoulas)
I am testing this now:
http://www.netbsd.org/~christos/vnode_iterator.diff
vfs_vnode_iterator_next should take the interlock and check for
VI_CLEAN|VI_CHANGING (and perhaps vwait if VI_CHANGING)
Date: Fri, 6 Jun 2014 12:56:53 -0500
From: David Young dyo...@pobox.com
Here is the proposal that I came up with many months (a few years?) ago
with input from Matt Thomas. I have tried to account for Matt's
requirements, but I'm not sure that I have done so.
For those
Date: Wed, 25 Jun 2014 11:24:16 +0200
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
The attached diff adds a new vcache operation
void
vcache_rekey(struct mount *mp, void *old_key, size_t old_key_len,
void *new_key, size_t new_key_len)
to
Date: Wed, 25 Jun 2014 12:04:30 +0200
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
Using memcpy(__UNCONST(node-vn_key.vk_key), new_key, new_key_len)
works but I'm not sure if __UNCONST is the right way to go.
I think __UNCONST is the right way to go -- removing const from the
API
Date: Tue, 1 Jul 2014 10:14:22 +0300
From: Staffan =?iso-8859-1?Q?Thom=E9n?= d...@shangtai.net
Hi, I have a soekris net6501 and using a current amd64 kernel with
either the 6.1.4 or daily from 2014-06-25 userland causes programs
linked with libpthread to crash. i386 works
Several graphics drivers use swap-backed buffers that sometimes need
to be wired into physical memory and made available for DMA by the
device. For buffers that are always wired and always mapped into KVA,
we can use bus_dmamem. But these buffers are numerous and large, so
they should not be
How can I remove all virtual mappings of a range of a uvm object, or
all virtual mappings of a physical page that is a device page rather
than a physical RAM page?
- I can't uvm_unmap(vm_map, start, end) because I don't know every
vm_map into which this uvm object has been mapped and where,
* by Taylor R. Campbell.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions
We don't have a nice easy lightweight way for a driver to ask that a
task be executed asynchronously in thread context. The closest we
have is workqueue(9), but each user has to do bookkeeping for a
different workqueue and incurs a long-term kthread, or ncpu long-term
kthreads, that are mostly
Date: Wed, 23 Jul 2014 11:31:14 +0200
From: Alan Barrett a...@cequrux.com
The multi-line BUILDINFO strings are truncated and folded to a
single line by uname(3), which is unhelpful, so I am inclined to
store them in a new kernel variable, exposed via a new sysctl
node,
Date: Sat, 26 Jul 2014 16:48:27 +0100
From: Mindaugas Rasiukevicius rm...@netbsd.org
I would expect a better problem statement even if it is a brain dump (one
sentence would have been enough). Are you trying to solve sleepable reader
problem? In such case, messing up
Date: Sat, 26 Jul 2014 20:13:08 +0200
From: Martin Husemann mar...@duskware.de
Why not extend softints so that they (optionally) provide a sleepable
context?
Softints are a relatively scarce resource compared to the four words
of memory that tasks occupy. Setting softints up and
Date: Sat, 26 Jul 2014 17:00:18 +0100
From: Mindaugas Rasiukevicius rm...@netbsd.org
Not against the idea, but frankly - the implementation looks somewhat
over-engineered.
Most of the engineering in the implementation went into satisfying the
request you made in private to limit the
1 - 100 of 691 matches
Mail list logo
