Invoking a system call from within the kernel

[valdis.kletnieks at vt.edu]

On Sat, 18 Nov 2017 14:09:31 -0500, Demi Marie Obenour said:

> Only whitelisted system calls would be allowed, such as open(), read(),
> and write().  Async getuid() would not be allowed.  Nor would async
> exit() or exit_group().

You missed the point - If you allow async calls, you need to deal with
the fact that this can change the semantics of things and introduce race
conditions.

What semantics does an async open() have? Under what conditions
does open() take long enough that doing it asyncronously provides
a benefit?

What system calls are you going to allow to be async?  (Hold that
thought for a moment, we'll return to it...)

> If an async call fails, the packet posted to the file descriptor
> contains the negative error code.

OK.. Was that a -5 error from async() itself, or a -5 from the async read()?

> Many programs (such as Node.js, NGINX, Firefox, Chrome, and every other
> GUI program) use an event loop architecture.  To maintain
> responsiveness, it is necessary to avoid blocking calls on the main
> thread (the thread that runs the event loop).  For filesystem
> operations, this is generally done by doing the operation in a thread
> pool.

And somehow, all those event loops are able to work just fine
without adding kernel infrastructure.  Given that track record,
you'll need to show a *large* benefit in order to get it into
the kernel.   Hint:  kdbus didn't make it in.

> There was a previous attempt to implement async system calls using the
> AIO interface.  Linus rejected it on the basis that an async system call
> API should be more general.

Do you have enough system calls to make it more general than AIO?




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20171118/55ea93a6/attachment.bin