xbdreq->req_sync.s_error = rep->status;
xbdreq->req_sync.s_done = 1;
Found by Brainy. I guess it's ok?
LGTM
+--+------+-+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:
nfsrvdescpl is not destroyed, and if we
were to reload the nfs module again, we would create a new pool with
the same pr_wchan.
Somehow, this doesn't sound like a very good idea.
+--+--+-----+
| Paul Goyette | PGP Key finge
structure (and how many to replace?)
+--+--+-----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--+-+
e gdb/crash to examine it).
+--+--+-----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--+-+
7;t include the SYSVSHM code.
+--+--+-----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 773
On Thu, 5 Nov 2015, Paul Goyette wrote:
Following up on my earlier modularization of the SYSV IPC code, I have
discovered that mips's pmap.c includes some SYSVSHM size in the calcs
for the system map sizes. At line 516 in arch/mips/mips/pmap.c we have
#ifdef SYSVSHM
Sysma
ments?
+--+--+-+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--+-+
On Thu, 5 Nov 2015, Christos Zoulas wrote:
In article ,
Paul Goyette wrote:
On Thu, 5 Nov 2015, Paul Goyette wrote:
Following up on my earlier modularization of the SYSV IPC code, I have
discovered that mips's pmap.c includes some SYSVSHM size in the calcs
for the system map sizes
aven't found it)?
[1] http://mail-index.netbsd.org/source-changes/2012/03/10/msg032675.html
+--+--+-+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at who
On Sat, 7 Nov 2015, Joerg Sonnenberger wrote:
On Sat, Nov 07, 2015 at 10:55:49AM +0800, Paul Goyette wrote:
I'd like to understand the rationale that makes POSIX sempahores a
non-optional component of the kernel, while POSIX message queues are
still optional. Both seem to be re
On Sat, 7 Nov 2015, Joerg Sonnenberger wrote:
On Sun, Nov 08, 2015 at 06:35:36AM +0800, Paul Goyette wrote:
On Sat, 7 Nov 2015, Joerg Sonnenberger wrote:
On Sat, Nov 07, 2015 at 10:55:49AM +0800, Paul Goyette wrote:
I'd like to understand the rationale that makes POSIX sempahores
On Sat, 7 Nov 2015, John Nemeth wrote:
On Nov 8, 7:22am, Paul Goyette wrote:
} On Sat, 7 Nov 2015, Joerg Sonnenberger wrote:
} > On Sun, Nov 08, 2015 at 06:35:36AM +0800, Paul Goyette wrote:
} >> On Sat, 7 Nov 2015, Joerg Sonnenberger wrote:
} >>> On Sat, Nov 07, 2015 at 10:5
re similar in
size to the SEMAPHORE module.
So, unless there are strenuous objections, I'm planning to resurrect
the SEMAPHORE module in about a week.
+--+--+-+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses
On Mon, 9 Nov 2015, Joerg Sonnenberger wrote:
On Mon, Nov 09, 2015 at 08:05:43AM +0800, Paul Goyette wrote:
Well, both EXEC_SCRIPT and COREDUMP are modularized, and they _are_
optional.
See part about modularity masturbation. Making things optional for the
sake of making them optional is
rger
wrote:
On Mon, Nov 09, 2015 at 08:05:43AM +0800, Paul Goyette wrote:
Well, both EXEC_SCRIPT and COREDUMP are modularized, and they _are_
optional.
See part about modularity masturbation. Making things optional for the
sake of making them optional is just as wrong.
Both EXEC_SCRIPT and CO
t - I can give this a quick test-drive tomorrow. Is there anything
specific I should be looking for? Or it is a simple Pass/Fail? :)
+--+--+-+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Re
On Fri, 13 Nov 2015, Paul Goyette wrote:
On Thu, 12 Nov 2015, Jonathan A. Kollasch wrote:
Hi,
Attached is a patch that should enable PCI MSI for pci(4)-attached re(4)
NICs. I would like both review of the code, and additional testing.
I've tested it successfully on amd64 -current w
hat would be
affected by (or otherwise care about) the proposed changes, a more wide-
spread discussion is unlikely.
[1] https://mail-index.netbsd.org/tech-kern/2011/09/21/msg011516.html
On Mon, 9 Nov 2015, Paul Goyette wrote:
On Mon, 9 Nov 2015, Joerg Sonnenberger wrote:
On Mon, Nov 09, 2015 a
On Fri, 13 Nov 2015, David Holland wrote:
On Fri, Nov 13, 2015 at 04:41:18PM +, David Holland wrote:
> On Fri, Nov 13, 2015 at 08:05:25PM +0800, Paul Goyette wrote:
> > One final attempt to summarize the objections that have been made:
> > [snip]
>
> One other thing:
goto out_wapbl;
sys/ufs/lfs/ulfs_quota2.c:out_wapbl:
sys/ufs/lfs/ulfs_snapshot.c:#include
sys/ufs/lfs/ulfs_vnops.c:#include
#
+--+--+-----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)
it
still might be useful from a documentation perspective.)
Oh, if/when this gets committed, it will require a bump of the kernel
version 7.99.xx due to the changes in internal structures. (Most
importantly, struct emul is shared by the kernel and several exec_*
and compat_* modules.)
+---
that case, the single l_sysent gets overwritten
and we now have no record that syscall #1 is still active.
+--+--+-+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--+-+
.
+--+--+-+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--+-+
tainly is
a possibility.
Can you please update the PR with this alternate suggestion?
+--+--+-+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--+-+
le auto-unload completely.
+--+--+-----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--+-+
On Tue, 17 Nov 2015, Paul Goyette wrote:
there's a fairly significant problem with this implementation.
you're only catching callers who use end up going through sy_call()
and that's not the majority. mostly they're called directly from
MD code. so to fix that, you
syscall dispatchers to use the wrapper, so it
seems that we don't need to do anything special. See [1] for the
relevant commit. If you can point out any other code that still
needs to be updated, please do!
[1]http://mail-index.netbsd.org/source-changes/2008/10/21/msg211565.html
+
d move on to other things.
+--+--+-----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--+-+
On Thu, 19 Nov 2015, Masao Uebayashi wrote:
On Wed, Nov 18, 2015 at 11:07 AM, Paul Goyette wrote:
Based on earlier comments, I've come up with a much-less-intrusive
set of changes. This time around, there are no bit masks and no new
members in any system structures. (I'm pret
s HOW the initial syscall
gets interrupted when the signal is being delivered (and HOW it gets
restarted when the handler returns) I would love an explanation!
+--+--+-----+
| Paul Goyette | PGP Key fingerprint: | E-mail addr
ble directly.
In any case, I've gone through filemon in some detail, and I think
I've fixed all of the really bad things. It should be safe to use,
although the only real use-case that anyone can identify is make(1).
+--+------+-
ides, I don't know enough about the vfs layer to get it right! :)
+--+--+---------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Ker
afraid that would just
encourage more bad behavior!
:)
+--+------+-+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--+-+
a compat_netbsd32_nfssrv
module (and if not already present, the "requires" would auto-load the
native nfsserver module), which would be able to syscall_establish()
its own package of syscalls.
Comments? Suggestion?
+--+--++
structive) comments that the community might offer.
+--+------++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer |
On Sun, 20 Dec 2015, Michael van Elst wrote:
p...@whooppee.com (Paul Goyette) writes:
The attached diffs (plus 2 new files) convert our existing raidframe
driver into a loadable module.
Does this still work with a non-MODULAR kernel?
Short answer: Yes
More details:
Whether or not a
On Sun, 20 Dec 2015, Rhialto wrote:
On Sun 20 Dec 2015 at 16:19:34 +0800, Paul Goyette wrote:
I like to think that I run a kernel from a third class:
HIGHLY-MODULAR
These kernels include only a minimum amount of built-in code,
and any additional functionality is loaded as
p? We've got lots of detailed technical man pages, but nothing
that would approach a rump-intro
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35
uded into the test program. None of the libraries
in /usr/lib seem to include any relevant symbols for the rump version of
this routine.
Any clues on how to do this?
+--+------++
| Paul Goyette | PGP Key fingerprint:
On Sun, 27 Dec 2015, Taylor R Campbell wrote:
Date: Sun, 27 Dec 2015 09:26:14 +0800 (PHT)
From: Paul Goyette
I'm looking into the failure of /usr/tests/rump/t_modautoload test, and
I've determined that the failure began after the introduction of the
MODULAR_DEFAUL
On Sun, 27 Dec 2015, Paul Goyette wrote:
I can't figure out how to get a rump_sysctlbyname() routine (or some
equivalent) to be included into the test program. None of the libraries
in /usr/lib seem to include any relevant symbols for the rump version of
this routine.
Any clu
s not clear to me what the DIAGNOSTIC code is supposed to prevent,
nor is it clear why the call to uio_setup_sysspace() doesn't set up
everything needed.
The same code in filemon seems to work just fine when it is passed a
file descriptor that refers to a "real" file.
Can so
make checks similar to "spec_write proc". filemon(4) works
fine when the "events" are written to a normal file; it fails when
asked to write to (for example) STDOUT_FILENO. :)
+--+--++
| Paul Goyette | P
On Tue, 5 Jan 2016, Taylor R Campbell wrote:
Date: Tue, 5 Jan 2016 09:13:01 +0800 (PHT)
From: Paul Goyette
Note: from the kernel map, 0x805e3120 is the address of
vmspace0, as would be expected from the above initialization code. The
map doesn't have anything
On Tue, 5 Jan 2016, Taylor R Campbell wrote:
Date: Tue, 5 Jan 2016 09:39:15 +0800 (PHT)
From: Paul Goyette
On Tue, 5 Jan 2016, Taylor R Campbell wrote:
> So I think DIAGNOSTIC condition is wrong. I think the right condition
> is probably uio->uio_vmspace == vmspa
file descriptor
* and return the file, holding a reference on the descriptor.
*/
file_t *
fd_getfile(unsigned fd)
{
...
-
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail ad
On Tue, 5 Jan 2016, Michael van Elst wrote:
p...@whooppee.com (Paul Goyette) writes:
I'm pretty sure that the device in question is the console terminal
driver /dev/console since the problem does not happen if filemon is
sending the entries to a "real" file. But I can
PPID CPU PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 455 4360 0 0 00 - DE tty00 0:00.00 (FM)
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)
On Tue, 5 Jan 2016, Michael van Elst wrote:
p...@vps1.whooppee.com (Paul Goyette) writes:
cv_wait() at cv_wait+0x116
fd_close() at fd_close+0x39a
fd_free() at fd_free+0x178
exit1() at exit1+0x10a
sys_exit() at sys_exit+0x3a
syscall() at syscall+0x9c
--- syscall (number 1) ---
So I guess I
On Wed, 6 Jan 2016, Paul Goyette wrote:
I need to figure out why this is a problem when filemon(4) "borrows" the fd
for stdout, but is not a problem when it borrows a real file.
OK, I figured out what's going on.
In the failure scenario, we have the following events:
o
have a periodic task run which checks to see if the file descriptor is
being closed; if yes, then the code could release the reference and
wake up the condvar waiter. But is this really a good thing to do? And
what would be an appropriate interval?
+--+---
On Tue, 5 Jan 2016, Thor Lancelot Simon wrote:
On Wed, Jan 06, 2016 at 11:38:00AM +0800, Paul Goyette wrote:
On Wed, 6 Jan 2016, Taylor R Campbell wrote:
Date: Tue, 5 Jan 2016 21:48:42 -0500
From: Thor Lancelot Simon
You can probably use workqueues for this. Looking at the manual page
On Wed, 6 Jan 2016, David Holland wrote:
On Wed, Jan 06, 2016 at 08:10:36AM +0800, Paul Goyette wrote:
> Does anyone have any good suggestions for how to arrange for another
> thread/lwp to run so it can remove the extra reference to the logging
> descriptor?
A better suggestion: r
/msg008307.html
[2] http://mail-index.netbsd.org/tech-kern/2016/01/05/msg019896.html
[3] http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50627
+------+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
hind our
backs?
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
ing the fd_getfile()-only-when-you-need-it change instead.
+--+------++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Deve
On
Behalf Of Paul Goyette
Sent: Wednesday, January 6, 2016 16:55
To: Taylor R Campbell
Cc: tech-kern@netbsd.org
Subject: Re: In-kernel process exit hooks?
Another possibility would be to change filemon(4) to do fd_getfile
each it needs to use the file descriptor. This makes it a little
more brit
erall.
You're doing the work, so having made my point, I'll let you make your
decision.
--Terry
-Original Message-
From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
Behalf Of Paul Goyette
Sent: Wednesday, January 6, 2016 21:31
To: Terry Moore
Cc: tech-k
ile will persist.
Hmmm. I will have to consider this option.
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
explicitly close the log-file fd
while it is still associated with the filemon, we get the same hang.
Next, I'm going to have a look at fd_getfile2()/fclose() and see if that
is a viable approach.
+--+--+--------+
| Paul Goyette
On Fri, 8 Jan 2016, Paul Goyette wrote:
The saga continues! :)
Next, I'm going to have a look at fd_getfile2()/fclose() and see if that
is a viable approach.
Hmmm. The comments in kern/kern_descrip.c for fd_getfile2() require
that the process is not allowed to fork or exit "a
/dev/filemon gets the lower number,
and no crash. But no guarantee, either!
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| K
, which would result in difficulties making[sic] a new
version. :)
+------+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
to change the semantics of filemon.
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE
is being closed. The all have the same fd (just in different
descriptor tables?)
So next I'm going to try kre's suggestion about using a "proper" refcnt
mechanism and see if that helps.
This filemon thing is a real beast! :)
On Fri, 8 Jan 2016, Paul Goyette wrote:
OK,
On Fri, 8 Jan 2016, Paul Goyette wrote:
Hmmm, option #3 doesn't work so well, after all!
I tried it when both the target and monitor processes were children of the
same shell process. Thus all three of these share the same 'struct file' for
their stdout, and the filemon_fd_c
ybody ?
Perhaps manually include ?
I also needed to manually include for MAXCOMLEN (used in
L66)
Cheers,
-bch
--
David A. Holland
dholl...@netbsd.org
!DSPAM:568f7d53105566048743086!
+--+--+--------+
| Paul Goyette | PGP Key
the process passed to
fd_getfile2.
Ah, OK, that makes sense.
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
On Fri, 8 Jan 2016, Taylor R Campbell wrote:
Date: Fri, 8 Jan 2016 16:52:28 +0800 (PHT)
From: Paul Goyette
Robert Elz wrote:
> That is, instead of a fd_getfile() without an (almost immediate)
> fd_putfile() so keeping ff_refcount incremented, in filemon, just do
>
&g
reference on the file
itself, rather than on the descriptor.
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer
sed diffs are attached.
So, I'll plan on committing this in the next couple of days. Unless
there is strong objection raised.
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)
ing for - ptrace is reparenting tracees.
If the process has been reparented, then its activity will no longer be
monitored and reported by filemon.
}
}
return (NULL);
}
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
owever, this is just my $0,03 as I don't contribute to this project.
Nothing prevents you from working on this and contributing any working
code. We're all volunteers here.
:)
+--+------++
| Paul Goyette | PGP Key fing
nd be done
with that nonsense?
Ciao,
Wolfgang
--
wolfg...@solfrank.net Wolfgang Solfrank
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF
else if (i == RTA_BRD)
+ break;
+ case RTA_BRD:
brd = sa;
+ break;
+ }
RT_ADVANCE(cp, sa);
}
if (ifa != NULL) {
!DSPAM:56a91bb7142006842815635!
+------+-
ication" does not include SMBus ALERT, since none of
our current i2c bus drivers supports this. We still need to poll the
sensor chip, and interrogate its status bits to determine if an alarm
condition exists.
+------+--+
cannabilized it for several parts, so it's probably no longer bootable.)
+--+--+--------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com
ty of dump(8), with the -X option:
dump -0au -h 0 -X -f- ${fs} | gzip -9 > $outfile
and it hasn't had any issues. But I'm not using raid, so that could be
a factor.
+--+------++
| Paul Goyette
n error" won't
help us to help you.
+--+------++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
er
herculean effort... :)
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
On Wed, 13 Apr 2016, Paul Goyette wrote:
Does this include xhci support for USB3 (ie, removal of the "experimental"
tag)?
FWIW, I finally got around to checking the status of USB3 on my machine.
Firstly, let me note that I do not have any USB3 peripherals. My only
USB3 equipm
quot; system.)
Further clue and/or guidance is requested!
[1] http://mail-index.netbsd.org/source-changes/2016/05/31/msg074994.html
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
On Mon, 6 Jun 2016, Robert Swindells wrote:
Paul Goyette wrote:
With a kernel built from today's sources (updated via anoncvs on
2016-06-05 at 13:29:32 UTC), I'm seeing the following messages when
loading the iic and bpf modules, resulting in load failure:
[snip]
Why doesn&#x
On Mon, 6 Jun 2016, Robert Swindells wrote:
Paul Goyette wrote:
On Mon, 6 Jun 2016, Robert Swindells wrote:
Paul Goyette wrote:
With a kernel built from today's sources (updated via anoncvs on
2016-06-05 at 13:29:32 UTC), I'm seeing the following messages when
loading the i
;t bother to release the mutex before
destroying it, then thread 2 stalls indefinitely.)
There currently doesn't seem to be a safe way to unload driver modules.
Any good MP-safe suggestions?
+--+--+----+
| Paul Goyette | PGP Key
memory address.
:)
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
On Tue, 7 Jun 2016, David Young wrote:
On Tue, Jun 07, 2016 at 06:28:11PM +0800, Paul Goyette wrote:
Can anyone suggest a reliable way to ensure that a device-driver
module can be _really_ safely detached?
The module could theoretically maintain an open/ref counter, but
making this MP-safe is
e and mapping it in multipple page-sized pieces would end up taking
more total space (due to page-rounding) and possibly exacerbate the
current situation.
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addr
On Tue, 7 Jun 2016, Taylor R Campbell wrote:
Date: Tue, 7 Jun 2016 18:28:11 +0800 (PHT)
From: Paul Goyette
Can anyone suggest a reliable way to ensure that a device-driver module
can be _really_ safely detached?
General approach:
1. Prevent new references (e.g., devsw_detach).
2
On Wed, 8 Jun 2016, Maxime Villard wrote:
Le 08/06/2016 à 08:57, Martin Husemann a écrit :
On Wed, Jun 08, 2016 at 05:57:47AM +0800, Paul Goyette wrote:
All of this sounds like a good idea. however, there are at least one or
two PRs out there related to limits on the amount of address space
On Wed, 8 Jun 2016, Paul Goyette wrote:
On Tue, 7 Jun 2016, Taylor R Campbell wrote:
Date: Tue, 7 Jun 2016 18:28:11 +0800 (PHT)
From: Paul Goyette
Can anyone suggest a reliable way to ensure that a device-driver module
can be _really_ safely detached?
General approach:
1. Prevent
wever, make
it rather difficult to maintain a valid ref-count!
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Deve
On Wed, 8 Jun 2016, Michael van Elst wrote:
p...@whooppee.com (Paul Goyette) writes:
See misfs/specfs/spec_vnops.c::spec_close().
yes, that would certainly explain the situation. It does, however, make
it rather difficult to maintain a valid ref-count!
specfs does the open refcounting
On Wed, 8 Jun 2016, Robert Elz wrote:
Date:Wed, 8 Jun 2016 22:16:28 +0800 (PHT)
From:Paul Goyette
Message-ID:
| Hmmm. Would it be valid, then, for my close() routine to reset the
| ref-count to zero rather than simply decrementing?
Do you really need a reference
toconf stuff at all? It's not clear to me where it even
gets added in the case of modularly-loaded pseudo-devices...
+------+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29
emoving it.
:)
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
Check out PR/43438
On Wed, 8 Jun 2016, Paul Goyette wrote:
On Wed, 8 Jun 2016, Maxime Villard wrote:
Le 08/06/2016 ? 08:57, Martin Husemann a ?crit :
On Wed, Jun 08, 2016 at 05:57:47AM +0800, Paul Goyette wrote:
All of this sounds like a good idea. however, there are at least one or
two
http://gnats.netbsd.org/50381
This PR was fixed more than 6 months ago, and pullups done to -7 and
-7-0 branches.
The uname looks like Michael's kernel was built in February 2016, but
from which-date sources?
+--+--+----+
| Pa
ge (source date Wed May 18 11:28:44 2016
+)
Great - thanks for checking!
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com
_bound and curlwp_boundx
Any other ideas? :)
- curlwp_bind and curlwp_bindx ?
(I like x for exit, and prefer a present-tense verb vs past tense.)
+--+--+----+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
201 - 300 of 654 matches
Mail list logo
