So, I've been kinda working toward the "more rust in gecko" goal, in my own space that just happened to be a good sandbox for it.
Last year I was brought over to help on WebAuthn, which needs access to USB HID for things like Yubikeys. I decided to write the lowest level cross platform parts of this in Rust, because it would give us safety in a place we desperately need it (the syscall/external bindings level). Tim Taubert and JC Jones are now leading this, and we're starting to look at landing the rust parts of this project soon. I had originally planned on taking this strategy for WebMIDI, but that project has unfortunately stalled due to priorities. My goal is doing this is being able to bring in rust from the bottom-up, on a part of the system that won't be part of any tight loops, just so we can start to get an idea of what this will look like for some (not all) systems. Right now, for webauthn, we go IPDL -> C++ -> C Bindings -> Rust. Once we have this solid, the plan is to start chipping our way up the chain to the IPDL boundary, though there are definitely obstacles to that, like our calls to NSS. Note that this project is certainly not reflective of the wide scope of bringing rust everywhere in the browser: - This specifically touches system components that are in C, so we don't have to deal with C++ binding issues yet. - It's not a particularly performance sensitive API, since human activity is in the loop - It doesn't really touch many other parts of the system at the moment. This could change depending on other factors in the project, movement in the spec, etc. WebAuthn isn't the only sandbox we could do this in. There are other portions, related to hardware or the HAL, either already written or still waiting to be implemented (gamepad, webmidi, etc), that we can use to try out some simple ideas while work is happening on other parts. There's also been talking of seeing if we could possibly share code with Servo this way, which is something I've been planning on trying via the Gamepad API. Once this project was over I was planning on talking to the rest of the team about doing a writeup, and would still love to see a blog post happen when it's all done and shipped, but it seems like making it part of this conversation would also be helpful. qDot On Wed, Jul 12, 2017 at 4:06 PM, Eric Rahm <er...@mozilla.com> wrote: > Interesting points. > > - *using breakpad* - was the problem that creating wrappers to access > the c/c++ code was too tedious? Could bindgen help with that, if not it > would be interesting gather some details about why it wouldn't work and > file bugs against it. > - *pingsender* - was something like https://hyper.rs/ not around when > you were working on it or is this a case of finding the things you want > can > be difficult in rust-land? Either way it might be a good idea for us to > put > together a list of "sanctioned" crates for various tasks. > > -e > > On Wed, Jul 12, 2017 at 1:36 AM, Gabriele Svelto <gsve...@mozilla.com> > wrote: > > > On 10/07/2017 12:29, Nicholas Nethercote wrote: > > > Hi, > > > What are the obstacles? Here are some that I've heard. > > > [...] > > > Anything else? > > > > In the past year I wrote two tools (minidump-analyzer and pingsender) > > that ship with Firefox but are separate executables so both were good > > candidates for being written in Rust in the first place. I implemented > > both in C++ because of different issues: > > > > - The minidump-analyzer relies on Google Breakpad machinery that is > > currently C++. It's being rewritten in Rust but it's not there yet and > > since we needed it to quickly get more crash information going the Rust > > route would have simply taken too long. It is a good candidate for being > > rewritten in Rust in the coming 12 months though. > > > > - The pingsender talks to our telemetry infrastructure so needs > > HTTP/HTTPS functionality but without linking with libxul. In this case > > if I had a crate that offered HTTP functionality I would have gone > > straight to Rust but alas it wasn't there. So instead it's a blob of > > platform-specific C++ that dlopen()s libcurl on Mac and Linux and relies > > on WININET on Windows. > > > > Gabriele > > > > > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
