I think it makes sense to decouple this from #451 and change the name to
something like "libzfs should use taskq in libfakekernel".
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Having libzpool use libfakekernel seems like the right answer to me.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/141#issuecomment-338625995
Thanks @gwr, that all makes sense to me. Without making any promises, I'll try
and pick this up again in a couple weeks, after the developer summit.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thinking about this some more, it _might_ be worthwhile considering the idea of
having libzpool just use libfakekernel, but I'm not sure we made that
sufficiently generic either. If not, perhaps extract what can be shared
(taskq) and promote it to a library of it's own, I guess.
--
You are
The libzpool taskq was there first, but was not sufficiently generic for
"fksmbd". (That was our "fake/debug" SMB server in a user process.)
We tried to make the taskq code in libfakekernel a little more generic, so it
_might_ make sense to work from that, but that's a decision for whoever
Thanks for your time and replies on this, @gwr :)
> Maybe a separate PR for the new lib might be easier...
Like this PR? IIRC, this only includes changes related to exposing the taskq
code for userspace, so maybe @andy-js is right, and I should just reopen this
PR so we can hash out the
Is there some place (i.e. a git branch) where I can pick up the new taskq
library?
I'd like to see how it goes replacing the one in libfakekernel with it.
Maybe a separate PR for the new lib might be easier...
--
You are receiving this because you are subscribed to this thread.
Reply to this
Should I go ahead and move forward with the work in #451?
Part of the reason I haven't tried to RTI that, are the issues brought up here.
#451 pulls a lot of this patch into it, and I was hesitant to upstream that,
until I had the time to field any concerns that would have been raised during
presumably, yes
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/141#issuecomment-338207035
--
openzfs-developer
Archives:
Well, then libfakekernel's taskq could be dropped as well once this is done?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/141#issuecomment-338203180
Well, the rest of what's in libfakekernel is probably not as "generic" as we
might like a libtaskq or libutaskq to be, so I'd probably go with a separate
library.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Maybe a new library would be better?
libfakekernel? ;-)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/141#issuecomment-338085360
--
That sounds like a good idea. libcmdutils is becoming a bucket for everything.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/141#issuecomment-338036480
I think it's time to reopen this. The problem was addressed in #359 by giving
the user space implementation a different name (utaskq). Apart from a minor
omission the changes look good.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
14 matches
Mail list logo
