> rust interface
The rust interface is currently only that of a TVM runtime, but that's
sufficient since the kernels are already memory safe. For maximum safety (but
slightly less flexibility from dynamic linking), one would use the
[non-bindings] runtime in `rust/runtime`. At least until TVM e
Ah, that makes total sense: a non-trivial implementation of DeviceAPI. Gee,
what a nice abstraction! I still kind of want the static graph, though :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tv
> mimic device-alloc with the fix size heap
>From
>[what](https://cboard.cprogramming.com/c-programming/124871-what-alternative-malloc.html)
> I [can](https://misra.org.uk/forum/viewtopic.php?t=260)
>[tell](https://stackoverflow.com/questions/16740435/c-memory-management-and-misra),
> writing a
It's definitely possible to fixup the TVM runtime so that the buffers are
included as part of the static library and to inline the pointers at compile
time. If the graph is also constructed at compile time (something I've been
wanting to do in the rust runtime anyway) then there's not much outsi
Closed #2887.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/2887#event-2345039552
Looks like we've reached consensus. Thanks @dingelish and @jethrogb for the
feedback. Work will now proceed on #2885.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/2887#issuecomment-49288
> minimal Rust runtime which might be useful as well here?
For sure. The Rust runtime has all of the features required for running syslib
modules, but it makes use of `alloc` and some tasteful unsafety, which are
disallowed by MISRA. If we really wanted to have an ultra-safe runtime, we
could d
Out of curiosity, what will be the difference between upstreamed r-s-s and
fortanix sgx? The Rust `libstd` implementation is already preferable to the
hugely complex and large TCB Intel C/C++ libs. Are you innovating on the runner?
--
You are receiving this because you are subscribed to this th
Okay, it's been two weeks on this RFC, so I'm going to prepare a pros/cons
summary of the discussion so far in preparation for further action.
Regarding the proposal to **replace SGX support in TVM with Fortanix**:
**Pros**
* tightly integrated into Rust ecosystem, which gives support for more
Ah finally! So much +1
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/2994#issuecomment-481341057
This idea actually comes a lot :P
https://github.com/dmlc/tvm/pull/2328#issuecomment-450001679
I know, for sure, that we could get good docs with _really good_ codegen like
that offered by Rust macros, but I also know for sure that we're not about to
rewrite TVM in Rust :)
I think that the boi
For others' reference, the [rust-sgx-sdk `Mutex` uses a spinlock provided by
the sgx
libc](https://github.com/intel/linux-sgx/blob/d10cabebb5512878e84f5d21cdf27c39c428ffe2/sdk/tlibthread/sethread_mutex.cpp#L74).
> depending on untrusted Mutex
Right, but all the untrusted OS can do is not provid
Well, if it's any consolation, the [rustc sgx thread implementation does the
exact same
thing](https://github.com/rust-lang/rust/blob/master/src/libstd/sys/sgx/thread.rs#L64)
as we're already doing. Might as well reduce code duplication, right?
--
You are receiving this because you are subscri
Hey @dingelish cool to see you here! Thanks a lot for the input. One point of
note for the TVM use-case is that the [TVM modules' thread pool already
requires cooperation from the
OS](https://github.com/dmlc/tvm/blob/master/rust/runtime/src/threading.rs#L132).
In almost all (or maybe actually a
(WIP PR: #2885)
**tl;dr**: The Rust compiler now has support for an SGX target, so users can
make their own enclaves using the unmodified TVM Rust runtime. In other words,
TVM no longer needs to explicitly support SGX.
The current TVM SGX infrastructure is built on
[baidu/rust-sgx-sdk](https:/
15 matches
Mail list logo
