2) On the client facing side (port 53), I'd very much hope for a
way to
do 'recvv' on datagram sockets, so I can retrieve a whole bunch of
UDP datagrams with only one kernel transition.
I want to highlight this point that Bert is making.
Whenever we talk about AIO and kernel
On Feb 15, 2007, at 11:11 AM, Ananiev, Leonid I wrote:
It returns -EIOCBRETRY without guaranteeing that kick_iocb() will be
called. This can lead to operations hanging
If EIOCBRETRY then generic_file_aio_write() will be recalled for the
same iocb.
Only if kick_iocb() is called. It won't
On Feb 15, 2007, at 3:32 PM, Ananiev, Leonid I wrote:
If EIOCBRETRY then generic_file_aio_write() will be recalled for the
same iocb.
Only if kick_iocb() is called. It won't be called if i_i_p2_r() was
the only thing to return -EIOCBRETRY.
It is not need to call kick_iocb()
for
as fs/aio.c and bio
completion both called aio_complete(). With this patch aio-stress sees -EIO.
Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
---
fs/aio.c| 109 ++
include/linux/aio.h | 30 +++
mm/filemap.c|4 -
3 f
I
*think* the patch is right, but picking the changes to the code and
watching
its movement at the same time is making my head spin.
Really? The only things that changed are the assignment from iocb-
>res (after testing pending_err) instead of the 'res' argument and
the dprintk.
b551e6cbf434 fs/aio.c
Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
---
fs/aio.c | 77 +
1 file changed, 43 insertions(+), 34 deletions(-)
--- a/fs/aio.c Mon Feb 19 13:09:01 2007 -0800
+++ b/fs/aio.c Mon Feb 19 13:12:04 2007 -0800
@@
as fs/aio.c and bio
completion both called aio_complete(). With this patch aio-stress sees -EIO.
Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
---
fs/aio.c| 49 +-
include/linux/aio.h | 30 +
mm/filemap.c|
Zach> So this patch introduces a helper, aio_propogate_error(),
...which is spelled incorrectly: aio_propagate_error.
Man, I am batting 1000! Randy also made fun of my 'intead'.
Zach> which queues post-submission errors in the iocb so that they are
Zach> given to the user completion
I would argue that one common cause of the EIO is userland
error (mmap concurrent with O_DIRECT), and EIO is the correct answer.
I disagree. That means that using the pagecache to synchronize
things like
the proposed online defragmentation will occasionally make O_DIRECT
users
fail.
On Feb 20, 2007, at 9:33 AM, Ananiev, Leonid I wrote:
There is change in the patch which is uncommented in preface.
Now aio_ring_insert_entry() is not called if req->ki_users>=1.
Before was called.
Could you comment it?
It is described in the patch description, though perhaps not
There are some strange O_DIRECT corner cases in here such that the
'last
writer' may actually be a 'last reader' and winning can mean have
a copy
of the page in page cache older than the copy on disk.
As long as it is marked dirty so that it eventually gets synced to
disk,
it shouldn't
On Feb 21, 2007, at 12:35 AM, Ken Chen wrote:
On 2/20/07, Ananiev, Leonid <[EMAIL PROTECTED]> wrote:
1) mem=1G in kernel boot param if you have more
2) unmount; mk2fs; mount
3) dd if=/dev/zero of= bs=1M count=1200
4) aiostress -s 1200m -O -o 2 -i 1 -r 16k
5) if i++<50 goto 2).
Would you
This is an interesting trick, but I'd like to consider hard whether
the added
complexity is worth it. Could you list the various other cases you
have in mind
which would want to use it ?
I'm happy to report that the sync case and the
invalidate_inode_pages2_range() case are the only two
Other questions really relate to the scheduling - Zach do you intend
schedule_fibrils() to be a call code would make or just from
schedule() ?
I'd much rather keep the current sleeping API in as much as is
possible. So, yeah, if we can get schedule() to notice and behave
accordingly I'd
ok, i think i noticed another misunderstanding. The kernel thread
based
scheme i'm suggesting would /not/ 'switch' to another kernel thread in
the cached case, by default. It would just execute in the original
context (as if it were a synchronous syscall), and the switch to a
kernel thread from
Since I still think that the many-thousands potential async operations
coming from network sockets are better handled with a classical event
machanism [1], and since smooth integration of new async syscall
into the
standard POSIX infrastructure is IMO a huge win, I think we need to
have a
But really, being a scheduler guy i was much more concerned about the
duplication and problems caused by the fibril concept itself - which
duplication and complexity makes up 80% of Zach's submitted patchset.
For example this bit:
[PATCH 3 of 4] Teach paths to wake a specific void * target
+ current->per_call = next->per_call;
Pointer instead of structure copy?
Sure, there are lots of trade-offs there, but the story changes if we
keep the 1:1 relationship between task_struct and thread_info.
- z
-
To unsubscribe from this list: send the line "unsubscribe
Or we need some sort of enter_context()/leave_context() (adopt mm,
files,
...) to have a per-CPU kthread to be able to execute the syscall
from the
async() caller context.
I believe that's what Ingo is hoping for, yes.
- z
-
To unsubscribe from this list: send the line "unsubscribe
The "result" of one async operation is basically a cookie and a result
code. Eight or sixteen bytes at most.
s/basically/minimally/
Well, yeah. The patches I sent had:
struct asys_completion {
longreturn_code;
unsigned long cookie;
};
That's as stupid as it
No, that's *really* it ;)
For syscalls, sure.
The kevent work incorporates Uli's desire to have more data per
event. Have you read his OLS stuff? It's been a while since I did
so I've lost the details of why he cares to have more.
Let me say it again, maybe a little louder this time:
- we'd need to do it in the kernel (which is actually nasty, since
different system calls have slightly different semantics - some
don't
return any error value at all, and negative numbers are real
numbers)
- we'd have to teach user space about the "negative errno"
mechanism, in
It has me excited in any case. Once anything even remotely testable
appears
(Zach tells me not to try the current code), I'll work it into MTasker
(http://ds9a.nl/mtasker) and make it power a nameserver that does
async i/o,
for use with very very large zones that aren't preloaded.
I'll be
That's not how the patches work right now, but yes, I at least
personally
think that it's something we should aim for (ie the interface
shouldn't
_require_ us to always wait for things even if perhaps an early
implementation might make everything be delayed at first)
I agree that we
On Feb 9, 2007, at 6:05 AM, Suparna Bhattacharya wrote:
On Fri, Feb 09, 2007 at 11:40:27AM +0100, Jiri Kosina wrote:
On Fri, 9 Feb 2007, Andrew Morton wrote:
@@ -1204,7 +1204,7 @@ generic_file_aio_read(struct kiocb *iocb,
const struct iovec *iov,
What I have there is not actually a full-blown file io descriptor,
because
there is no file or offset. It is just an iovec iterator (so maybe
I should
rename it to iov_iter, rather than iodesc).
I think it might be a nice idea to keep this iov_iter as a standalone
structure, and it could be
this printk all, just remove it.
Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
---
fs/aio.c |1 -
1 file changed, 1 deletion(-)
--- a/fs/aio.c Tue Mar 27 14:56:08 2007 -0700
+++ b/fs/aio.c Tue Mar 27 14:56:49 2007 -0700
@@ -136,7 +136,6 @@ static int aio_setup_ring(struct
We don't need this printk all, just remove it.
("at all". Sigh.)
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
+#define pipe_kmap_atomic(page, type) pipe_kmap(page)
+#define pipe_kunmap(page) do { } while (0)
+#define pipe_kunmap_atomic(page, type) do { } while (0)
Please don't drop arguments in stubs. It can let completely broken
code compile, like:
Does this look OK?
Almost...
#ifdef CONFIG_HIGHMEM
static inline void pipe_kunmap_atomic(void *addr, enum km_type type)
#else /* CONFIG_HIGHMEM */
static inline void pipe_kunmap_atomic(struct page *page, enum
km_type type)
- z
-
To unsubscribe from this list: send the line "unsubscribe
There are members of task_struct which are only used by a given call chain to
pass arguments up and down the chain itself. They are logically thread-local
storage.
The patches later in the series want to have multiple calls pending for a given
task, though only one will be executing at a given
This patch introduces the notion of a 'fibril'. It's meant to be a lighter
kernel thread. There can be multiple of them in the process of executing for a
given task_struct, but only one can every be actively running at a time. Think
of it as a stack and some metadata for scheduling them inside
The addition of multiple sleeping fibrils under a task_struct means that we
can't simply wake a task_struct to be able to wake a specific sleeping code
path.
This patch introduces task_wake_target() as a way to refer to a code path that
is about to sleep and will be woken in the future. Sleepers
This very rough patch series introduces a different way to provide AIO support
for system calls.
Right now to provide AIO support for a system call you have to express your
interface in the iocb argument struct for sys_io_submit(), teach fs/aio.c to
translate this into some call path in the
This finally does something useful with the notion of being able to schedule
stacks as fibrils under a task_struct. Again, i386-specific and in need of
proper layering with archs.
sys_asys_submit() is added to let userspace submit asynchronous system calls.
It specifies the system call number
I looked at this approach a long time ago, and basically gave up
because
it looked like too much work.
Indeed, your mention of it in that thread.. a year ago?.. is what got
this notion sitting in the back of my head. I didn't like it at
first, but it grew on me.
I heartily approve,
So we should limit these to basically have some maximum concurrency
factor, but rather than consider it an error to go over it, we'd
just cap
the concurrency by default, so that people can freely use asynchronous
interfaces without having to always worry about what happens if their
resources
Btw, I noticed that you didn't Cc Ingo. Definitely worth doing. Not
just
because he's basically the normal scheduler maintainer, but also
because
he's historically been involved in things like the async filename
lookup
that the in-kernel web server thing used.
Yeah, that was dumb. I had
On Jan 31, 2007, at 12:58 AM, Andi Kleen wrote:
Do you have any numbers how this compares cycle wise to just doing
clone+syscall+exit in user space?
Not yet, no. Release early, release often, and all that. I'll throw
something together.
- z
-
To unsubscribe from this list: send the
- We would now have some measure of task_struct concurrency. Read
that twice,
it's scary.
That's the one scaring me in fact ... Maybe it will end up being an
easy
one but I don't feel too comfortable...
Indeed, that was my first reaction too. I dismissed the idea for a
good six
Does that mean that we might not have some cases where we'd need to
make
sure we do things differently? Of course not. Something migt show up.
Might, and has. For a good time, take journal_info out of
per_call_chain() in the patch set and watch it helpfully and loudly
wet itself. There
Btw, this is also something where we should just disallow certain
system
calls from being done through the asynchronous method.
Yeah. Maybe just a bitmap built from __NR_ constants? I don't know
if we can do it in a way that doesn't require arch maintainer's
attention.
It seems like
The only thing I saw in Zach's post against the use of threads is that
some kernel API would change. But surely if this is the showstopper
then
there must be some better argument than sys_getpid()?!
Haha, yeah, that's the silly example I keep throwing around :). I
guess it does leave a
On Jan 31, 2007, at 9:21 AM, Andi Kleen wrote:
On Wednesday 31 January 2007 18:15, Zach Brown wrote:
On Jan 31, 2007, at 12:58 AM, Andi Kleen wrote:
Do you have any numbers how this compares cycle wise to just doing
clone+syscall+exit in user space?
Not yet, no. Release early, release
without linking it into the system lists. The reason I don't think
this
approach works (and I looked at it a few times) is that many things
end
up requiring special handling: things like permissions, signals,
FPU state,
segment registers
Can you share a specific example of the
On Jan 31, 2007, at 2:50 AM, Xavier Bestel wrote:
On Tue, 2007-01-30 at 19:02 -0800, Linus Torvalds wrote:
Btw, this is also something where we should just disallow certain
system
calls from being done through the asynchronous method.
Does that mean that doing an AIO-disabled syscall will
Take FPU state: memory copies and RAID xor functions use MMX/SSE and
require that the full task state be saved and restored.
Sure, that much is obvious. I was hoping to see what FPU state
juggling actually requires. I'm operating under the assumption that
it won't be *terrible*.
Task
Do you have any userspace code that can be used to get started
experimenting
with your fibril based AIO stuff?
I only have a goofy little test app so far:
http://www.zabbo.net/~zab/aio-walk-tree.c
It's not to be taken too seriously :)
I want to try it on from a userspace
let me clarify this: i very much like your AIO patchset in general, in
the sense that it 'completes' the AIO implementation: finally
everything
can be done via it, greatly increasing its utility and hopefully its
penetration. This is the most important step, by far.
We violently agree on
Wooo ...hold on ... I think this is swinging out of perspective :)
I'm sorry, but I don't. I think using the EIOCBRETRY method in
complicated code paths requires too much maintenance cost to justify
its benefits. We can agree to disagree on that judgement :).
- z
-
To unsubscribe from
That sounds like a programming error, don't you think? Maybe
returning EINVAL is the right approach?
Maybe. I think I'd prefer to be permissive and queue as much as
possible, but it's not a strong preference. Returning EINVAL seems
ok, too.
- z
-
To unsubscribe from this list: send the
Priorities cannot be shared, as they have to adapt to the per-request
priority when we get down to the nitty gitty of POSIX AIO, as
otherwise
realtime issues like keepalive transmits will be handled incorrectly.
Well, maybe not *blind* sharing. But something more than the
disconnect
First, I'll NAK this and all AIO patches until the patch description
says that it's been run through the regression tests that we've started
collecting in autotest. They're trivial to run, never fear:
cd /usr/local
svn checkout svn://test.kernel.org/autotest/trunk/client autotest
cd autotest
> Sorry I wasn't thorough enough. And partially because I was worried
> about changing structure type for user space facing struct aio_ring.
> Now that I looked through all arches, it looks safe as all arch's
> atomic_t has the same size as int.
> Here is the updated patch.
> @@ -144,7 +144,7
> Ken uses the other (superior!) way of implementing ringbuffers: the head
> and tail pointers (the naming of which AIO appears to have reversed) are
> not constrained to the ringsize - they are simply allowed to wrap through
> 0xfff.
A-ha! That sure sounds great.
I'd be happy to see the
> >I have mixed feelings. I think the userspace getevents support was
> >poorly designed and the simple fact that we've gone this long without it
> >says just how desperately the feature isn't needed.
>
> I kept on getting requests from application developers who want that
> feature. My initial
> > I kept on getting requests from application developers who want that
> > feature. My initial patch was dated back May 2004.
>
> The right way to do it involves synchronization between the kernel side
> io_getevents() and the userspace code pulling events out of the ring.
> Alan Cox
On Tue, Apr 17, 2007 at 03:18:56PM +0400, Pavel Emelianov wrote:
> There are many places in the kernel where the construction like
>
>foo = list_entry(head->next, struct foo_struct, list);
>
> are used.
> The code might look more descriptive and neat if using the macro
>
>
On Mon, Jun 04, 2007 at 12:31:45PM -0400, Jeff Dike wrote:
> Syslets seem like a fundamentally good idea to me, but the current
> implementation, using CLONE_THREAD threads, seems like a basic
> problem.
It has remaining problems that need to be addressed, yes.
> First, there are signals. If
g() to -1 and then return it.
__exec_atom() sets task_ret_reg() to NULL if there's a chance that it will
block while executing the syscall in the atom.
Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
diff -r f0d8ee165e2e kernel/async.c
--- a/kernel/async.cThu Jun 07 14:32:31 2007 -0700
+++ b
I don't like it :-)
For a fundamental reason or because it happens to not work yet? :)
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
The latter - it fails the test that I posted.
OK, good. That's easy enough to fix :) I'll send out a tested version.
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
> FWIW, I believe Andrew's point was that critical information for Joe
> Enduser (and Joe Patch-Ho) was lacking in the original changelog.
and don't forget Joe eCryptfs-Maintainer-2-Years-In-The-Future.
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
I'm pleased to announce the availability of version 6 of the syslet subsystem.
Ingo and I agreed that I'll handle syslet releases while he's busy with CFS. I
copied the cc: list from Ingo's v5 announcement. If you'd like to be dropped
(or added), please let me know.
The v6 patch series against
> .. so don't keep us in suspense. Do you have any numbers for anything
> (like Oracle, to pick a random thing out of thin air ;) that might
> actually indicate whether this actually works or not?
I haven't gotten to running Oracle's database against it. It is going
to be Very Cranky if
> You should pick up the kevent work :)
I haven't looked at it in a while but yes, it's "on the radar" :).
> Having async request and response rings would be quite useful, and most
> closely match what is going on under the hood in the kernel and hardware.
Yeah, but I have lots of competing
> Yeah, it'll confuse CFQ a lot actually. The threads either need to share
> an io context (clean approach, however will introduce locking for things
> that were previously lockless), or CFQ needs to get better support for
> cooperating processes.
Do let me know if I can be of any help in this.
> due to the added syscall. (Maybe we can just get that reserved
> upstream now?)
Maybe, but we'd have to agree on the bare syslet interface that is being
supported :).
Personally, I'd like that to be the simplest thing that works for people
and I'm not convinced that the current syslet-specific
On Wed, May 30, 2007 at 02:49:03PM +0200, Peter Zijlstra wrote:
>
> Use the lockdep infrastructure to track lock contention and other lock
> statistics.
I really like the sound of this.
Has anyone given you an indication of when it might be merged?
- z
-
To unsubscribe from this list: send the
> +#ifndef CONFIG_STABLE
> /*
>* We should return 0 if size == 0 (which would result in the
>* kmalloc caller to get NULL) but we use the smallest object
> @@ -81,6 +82,7 @@ static inline int kmalloc_index(size_t s
>* we can discover locations where we do 0 sized
> cachemiss_thread should explicitly return 0 or error instead of
> task_ret_reg(current) (which is -ENOSYS anyway) because
> async_thread_helper is careful to put the return value in eax anyway.
Can you explain what motivated you to send out this patch?
It used to return 0. It was changed
> Add a bunch of includes to sys.h and syslet.h to kill off compilation
> warnings.
This, and the patches which add tests, all look great to me.
Ingo, are you patching up your tests or do you want me to take care of
these?
- z
-
To unsubscribe from this list: send the line "unsubscribe
> the demos I sent out. Dunno about the existing ones, but I bet they do
> the same.
Hmm, they didn't when I ran them, but I'll give yours a try and take a
closer look. Thanks for taking the time to bring it up.
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> I fear the consequences of this change :(
I love it. In the past I've lost time by working with patches which
didn't quite realize that ext3 holds a transaction open during
->direct_IO.
> Oh well, please keep it alive, maybe beat on it a bit, resend it
> later on?
I can test the patch to
> Second, Oracle is now working on Btrfs (if ever a FS needed a better
> name... is that pronounced ButterFS?).
(In our silliest moments, yes. Absolutely.)
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
> > I'd just like to take the chance also to ask about a VM/FS meetup some
> > time around kernel summit (maybe take a big of time during UKUUG or so).
Yeah, I'd be interested.
> More issues:
- chris mason's patches to normalize buffered and direct locking
- z
-
To unsubscribe from this list:
another field like
.map_bh.b_state where we rely on zeroing but don't enforce it in the
code.
Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
---
fs/direct-io.c | 18 +-
1 files changed, 1 insertions(+), 17 deletions(-)
diff --git a/fs/direct-io.c b/fs/direct-io.c
index 1
It's only safe to dereference the dio after releasing the
lock if the final reference was just dropped. Another CPU might free
the dio in bio completion and reuse the memory after this path drops the
dio lock but before the BUG_ON() is evaluated.
This patch passed aio+dio regression unit tests and a
the BUG_ON(). But unfortunately, our perf. team is able reproduce the
problem.
What are they doing to reproduce it? How much setup does it take?
Debug indicated that, the ret2 == 1 :(
That could be consistent with the theory that we're racing with the
dio struct being freed and reused
fyi, I dropped the earlier patch and now we have nothing. Please
let's get all
this sorted out in time for 2.6.23. Which is still many weeks away
so there is
plenty of time to prepare something which was carefully reviewed
and well-tested,
thanks.
I was distracted by OSCON last week.
I am also taking a look at it right now.
Are we having a race to write a little test app that reproduces the
problem? :)
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Jul 30, 2007, at 2:58 PM, Badari Pulavarty wrote:
On Mon, 2007-07-30 at 14:45 -0700, Zach Brown wrote:
I am also taking a look at it right now.
Are we having a race to write a little test app that reproduces the
problem? :)
Nope. Feel free to write the test case. I am just looking
On Jul 30, 2007, at 2:58 PM, Badari Pulavarty wrote:
On Mon, 2007-07-30 at 14:45 -0700, Zach Brown wrote:
I am also taking a look at it right now.
Are we having a race to write a little test app that reproduces the
problem? :)
Nope. Feel free to write the test case.
Well, I'm having
Okay. Here is the fix for the problem.
Yeah, that looks right from my understanding too. Thanks, Badari.
Signed-off-by: Badari Pulavarty <[EMAIL PROTECTED]>
Acked-by: Zach Brown <[EMAIL PROTECTED]>
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
Does a patch like this work? I don't have any test-cases, but it
would be
good to have something like this tested and passed back with proper
explanations and sign-offs.
It should, yeah.
I'm bringing up a more capable IO testbed over here. I'll run it
through the tests I have once that
If you're soliciting opinions, I think I tend to prefer the feel of the
code paths after the changes. I don't know the benefits of the change
are worth the risk in unmaintained file systems, though.
> + return ERR_PTR(PTR_ERR(inode));
This caught my eye. Surely we can do better :).
return ERR_PTR(PTR_ERR(inode));
I tend to prefer the latter.
It seems like a pretty noisy way to get a (void *) cast :/. Maybe a
function that has the cast but makes sure it's only used for IS_ERR()
pointers?
/* haha, continuing the fine tradition of terrible names in this
> Hopefully I will get some attention from those that are responsible for
> fs/direct_io.c
[ many days later, I find this amongst the lkml noise. ]
> This patch converts the i_alloc_sem into a compat_rw_semaphore for the -rt
> patch. Seems that the code in fs/direct_io.c does some nasty logic
On Oct 1, 2007, at 1:39 PM, Peter Zijlstra wrote:
On Mon, 2007-10-01 at 12:52 -0700, Zach Brown wrote:
Do you have any suggestions for locking constructs that RT would
prefer?
Basically, anything that maps to a simple mutex. Anything more complex
gets real messy real quick.
I'm worried
This looks more like a completion. Actually, completions don't have PI
either, but they are usually OK.
Yeah, true.
When more info becomes available, I will definitely CC the linux-
fsdevel
list. Thanks for letting me know about it. (I usually get confused
by all
the different lists that
Ulrich Drepper wrote:
> The following patches provide an alternative implementation of the
> sys_indirect system call which has been discussed a few times.
> This no system call allows us to extend existing system call
> interfaces with adding more system calls.
I might quarrel with some details,
> BTW, I've botched the x86-on-x86_64 support. I have a patch but need to
> patch it before I'll submit v3 of the patch set. If you want to work on
> the patch and get syslet support going, let me know, I'll send the
> latest version.
I probably won't come around to trying sys_indirect with
David Miller wrote:
> From: Ulrich Drepper <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2007 01:53:14 -0500
>
> FWIW, I think this indirect syscall stuff is the most ugly interface
> I've ever seen proposed for the kernel.
Well, there's no XML in /proc :) :).
But, yes, I agree that the internal code
> +union indirect_params {
> + struct {
> +int flags;
> + } file_flags;
> +};
Have you given thought to having to perform compat translation on this?
Today it's only copied directly from the user pointer into the union
in the task_struct.
I'd love if we could only use fixed-width fields
Ingo Molnar wrote:
> cool patchset. Small nit, the series is not bisectable:
Yeah, in a few places.
Uli, this is super easy to test if you maintain the patches with guilt.
With some easy scripting around guilt push you can verify that the
series builds as each patch is applied.
- z
-
To
> Since there is no legacy interface to worry about all members added to
> the structure can and should be neutral of the word size.
OK, perhaps add a giant comment warning about that. History tells us
that people will get it wrong.
> We've done
> this with some syscalls already (like pread64)
> This was mentioned in one of my mails. I added the parameter to
> accommodate Linus's and Zack's idea to use the functionality for syslets
> as well. Not really a multiplexer, it is meant to be a "execute
> synchronously or asynchronously" flag. In the latter case an additional
> parameter
> That's only because you're being, deliberately or accidentally, vague
> about what your actual (as opposed to imagined) requirements are.
Maybe I can help by summarizing how syslets fit in to this.
Currently the syslet patches add a single submission call which includes
an argument which is a
>>> Where does this INDIRECT_PARAM() macro get defined? I do not
>>> see it being defined anywhere in these patches.
>> Defined in :
>>
>> +#define INDIRECT_PARAM(set, name) current->indirect_params.set.name
>>
>> Not my idea, I was following one review comment.
>
> This was not in the patches
> The patch given below replaces the goto-loop by a while-based one.
That certainly looks fine. I would also replace the 'return' with
'break', but I guess that's more of a question of personal preference.
> Besides, it removes the export for the same routine, because there are
> no users for
601 - 700 of 1040 matches
Mail list logo
