WEBVTT 00:00.000 --> 00:02.000 You 00:30.000 --> 00:32.000 You 01:00.000 --> 01:02.000 You 01:31.000 --> 01:32.000 Yes 01:32.000 --> 01:34.000 Thank you for the introduction 01:36.000 --> 01:40.000 In this presentation, I would like the report about 01:40.000 --> 01:44.000 Attempt of mine to support yet another kernel for the 01:44.000 --> 01:46.000 Genode framework because we have so few 01:46.000 --> 01:52.000 And so I will first as go a bit into detail about it 01:52.000 --> 01:56.000 Genode OS framework what it is in case some of you don't know 01:56.000 --> 02:00.000 And then I will speak a bit about this 02:00.000 --> 02:02.000 And what happened last year 02:02.000 --> 02:08.000 Since intention was from my side to go a bit through the history of the supported microcunals 02:08.000 --> 02:10.000 And but I have to 02:10.000 --> 02:14.000 Cut away a lot of the part of the presentation because I have no time for that 02:14.000 --> 02:19.000 Actually, so it's been quite short since second part and then I actually want to talk about 02:19.000 --> 02:21.000 The work I did 02:21.000 --> 02:24.000 For small components, but if you have like qt 02:24.000 --> 02:29.000 Chrome engine a browser you will find this really nice 02:29.000 --> 02:33.000 The other point is that Genode now comes as a package management system 02:33.000 --> 02:37.000 That means once you have written your component, you can package it, sign it and upload it 02:37.000 --> 02:41.000 And during your runtime deploy it while package management mentioned it 02:41.000 --> 02:45.000 But of course, you can also stay static if you want if you had just one 02:45.000 --> 02:49.000 Ship 02:49.000 --> 02:55.000 For an IoT device and image you may stay static 02:55.000 --> 02:59.000 Since the end of the last year, we have this sort book which is about how to get 02:59.000 --> 03:05.000 In a modern way applications running on top of Genode, without touching the build system at all 03:05.000 --> 03:07.000 Which was beforehand necessary 03:07.000 --> 03:13.000 First book is about the basics, about the philosophy of Genode 03:13.000 --> 03:17.000 And the second book guide you if you have to enable 03:17.000 --> 03:21.000 Another armboard and you need to enable it to drive 03:21.000 --> 03:23.000 So the second book will help you 03:23.000 --> 03:28.000 Now you have all this components and you can 03:28.000 --> 03:33.000 And some one has to build an OS out of it 03:33.000 --> 03:40.000 So it's not seeing you catch us boot, it's the job of the user of the Genode OS framework to make something useful out of it 03:40.000 --> 03:45.000 So this is how changed this beginning of 2017, where we shipped our own 03:45.000 --> 03:51.000 On the redness system, where we had regular releases two times per year 03:51.000 --> 03:58.000 Which should serve as day to day OS for community and for the developers on consumer devices 03:58.000 --> 04:04.000 So that we can work on some on its brand and we can enjoy what we had done to month before 04:04.000 --> 04:08.000 So it's got the SS based on Genode OS frame book releases in settings 04:08.000 --> 04:14.000 And you get a very tiny base OS, it's like sort of make up rights that makes it device detection 04:14.000 --> 04:19.000 Starts a wide drive or configure everything so that you end up in a tight UI 04:19.000 --> 04:22.000 Where you then can start new components 04:22.000 --> 04:26.000 So those components are provided 04:26.000 --> 04:31.000 You have to download it, download it, they are provided in a better way 04:31.000 --> 04:37.000 That means we have not one big app stores, so everyone of us can provide packages 04:37.000 --> 04:39.000 And you can decide what you want to take 04:39.000 --> 04:41.000 And as soon as the system is up 04:41.000 --> 04:44.000 Then typically what you 04:44.000 --> 04:48.000 The most users of us do, we want to have a window manager 04:48.000 --> 04:52.000 Then we have several native browsers running on top 04:52.000 --> 04:57.000 Which are chromium based or you want to stay in the virtual machine monitor with your Firefox 04:57.000 --> 05:00.000 And they have multiple virtual machine monitors 05:00.000 --> 05:03.000 And we have a lot of native applications 05:03.000 --> 05:07.000 This is a bit of a few, for example, I'm running currently natively on Skype 05:07.000 --> 05:10.000 So I'm switching into control fuel in settings 05:10.000 --> 05:12.000 GPU applications and so on 05:12.000 --> 05:15.000 And optionally there's also a POSIX run time 05:15.000 --> 05:19.000 This folks in Montix is that you can run your beloved new tools 05:19.000 --> 05:21.000 What is the option? 05:21.000 --> 05:24.000 It's not a Genode OS, it's not POSIX 05:24.000 --> 05:29.000 But as a hardware device, it's a consumer device that we support 05:29.000 --> 05:34.000 Right-hand side, you see frame work, X86 notebook 05:34.000 --> 05:37.000 In the middle you have a pine phone running scalp 05:37.000 --> 05:40.000 And the left-hand side, an arm-based board 05:40.000 --> 05:45.000 And since the end of last year, we additionally support the mount pocket reform 05:45.000 --> 05:47.000 Which is also running scalp 05:47.000 --> 05:53.000 And yeah, so what happens last year regarding the two 05:53.000 --> 05:57.000 Reliesus we had several features technical ones 05:57.000 --> 06:00.000 One-to-names, the user was a bit features 06:00.000 --> 06:04.000 With the end of the last year we have now a graphical user interface 06:04.000 --> 06:06.000 That you can easily configure the resolution 06:06.000 --> 06:08.000 When you attach connector 06:08.000 --> 06:11.000 And additionally, as this was 06:11.000 --> 06:14.000 We have now panorama support 06:14.000 --> 06:19.000 That means you can have large virtual screen across all the displays 06:19.000 --> 06:22.000 And you can configure it fine granular 06:22.000 --> 06:27.000 This is a nice feature and it took quite a time to get the driver running 06:27.000 --> 06:30.000 The whole UI stack up to the applications 06:30.000 --> 06:34.000 So it was tough white, but what's cool? 06:34.000 --> 06:44.000 And another user with the feature was actually that we now added to the Skype 06:44.000 --> 06:48.000 To the S system, also the Spentry Zoom support for X86 06:48.000 --> 06:52.000 The feature itself was more than to frame work already beforehand 06:52.000 --> 06:56.000 But to convince all the drivers working nicely 06:56.000 --> 06:59.000 When you want to go to the Spentry Zoom time 06:59.000 --> 07:02.000 And here you mainly see the interface 07:02.000 --> 07:05.000 You have to enable a bit more HPI support 07:05.000 --> 07:09.000 And then by button pops up and you can try to suspend the system 07:09.000 --> 07:11.000 And hopefully it will come back 07:11.000 --> 07:14.000 You know, there's only one type of RAM 07:14.000 --> 07:16.000 Which a component got assigned 07:16.000 --> 07:19.000 This includes the user part and also the implicit kernel part 07:19.000 --> 07:22.000 Page table, kernel resources and so on 07:22.000 --> 07:25.000 If there's some, let's say 07:25.000 --> 07:29.000 If you didn't know what the cost for kernel resources 07:29.000 --> 07:31.000 It's problematic 07:31.000 --> 07:35.000 If there's a fixed pool in the kernel, which can be exhausted 07:35.000 --> 07:37.000 But it actually has a lot of memories 07:37.000 --> 07:40.000 And you cannot stop any components anymore 07:40.000 --> 07:42.000 It's a bit problematic 07:42.000 --> 07:46.000 So ideally there's some dynamic ways, some flexible way to talk to the kernel 07:46.000 --> 07:48.000 About memory usage 07:48.000 --> 07:52.000 So that's a Gino can really account it correctly 07:52.000 --> 07:58.000 The other point is, ideally, there should be non-blocking kernel interfaces 07:58.000 --> 08:03.000 A little bit because on Gino, we have this style of event programming interface 08:03.000 --> 08:05.000 You know, probably you have one thread 08:05.000 --> 08:07.000 It gets a synchronous IPC from the outside 08:07.000 --> 08:09.000 That's something, it's already 08:09.000 --> 08:12.000 Or you get an asynchronous event, do something and it's ready 08:12.000 --> 08:15.000 When it's wet, for some reason, has to block on a Cisco for a long time 08:15.000 --> 08:17.000 Like, I want to wait for interrupt 08:17.000 --> 08:19.000 And this red cannot do it in the meantime, something else 08:19.000 --> 08:21.000 It's hard for us 08:21.000 --> 08:26.000 And we have to solve this something differently 08:26.000 --> 08:29.000 The other part is, if you want my deco support 08:29.000 --> 08:32.000 Currently, the assumption is that there is just 08:32.000 --> 08:34.000 Cosco IPC support provided by the kernel 08:34.000 --> 08:36.000 So if you have a service on CBO5 08:36.000 --> 08:39.000 And you are running on one, there is no support 08:39.000 --> 08:41.000 In, like, moving first 08:41.000 --> 08:45.000 Set guide to the ASUS CPU on five and make a local IPC 08:45.000 --> 08:48.000 So there is just a assumption, there is Cosco IPC support 08:48.000 --> 08:49.000 It must be there 08:49.000 --> 08:52.000 And, optionally, of course, it's virtualization 08:52.000 --> 08:54.000 So the framework itself does not require virtualization 08:54.000 --> 08:56.000 But of course, the user on top 08:56.000 --> 08:58.000 Want to run a virtual machine 08:58.000 --> 08:59.000 Right? 08:59.000 --> 09:03.000 So, for the presentation, I looked at how our release notes 09:03.000 --> 09:05.000 And try to come up with some timeline about 09:05.000 --> 09:08.000 When, when, which tunnel got added to Gnode 09:08.000 --> 09:10.000 And how long it was supported? 09:10.000 --> 09:13.000 And so, if you see a line where it stops 09:13.000 --> 09:16.000 Some to the middle, some to the support was removed 09:16.000 --> 09:19.000 So, it's a year and a month 09:19.000 --> 09:21.000 When something got added 09:21.000 --> 09:25.000 And, now, I would like 09:25.000 --> 09:28.000 Look, a bit into the kernel 09:28.000 --> 09:30.000 So, it's a plus kernel 09:30.000 --> 09:32.000 Since the beginning is the Linux kernel 09:32.000 --> 09:34.000 It's obviously not a micro kernel kernel 09:34.000 --> 09:36.000 It's a monolidic one 09:36.000 --> 09:38.000 So, nice thing about this is simply 09:38.000 --> 09:40.000 It's for clapping prototyping, it's really nice 09:40.000 --> 09:42.000 So, on Linux, you must imagine 09:42.000 --> 09:44.000 It's like a middleware layer, Gnode 09:44.000 --> 09:46.000 And each Gnode component 09:46.000 --> 09:48.000 It's just a Linux task 09:48.000 --> 09:50.000 And you can debug it easily, you can attach 09:50.000 --> 09:51.000 And so on 09:51.000 --> 09:53.000 So, other kernels are micro kernels 09:53.000 --> 09:55.000 For micro kernels, which we are at the time 09:55.000 --> 09:57.000 When they got added 09:57.000 --> 10:00.000 The data of the arts and on work 10:00.000 --> 10:03.000 At least in the bubble, we are living 10:03.000 --> 10:06.000 And, they are still around 10:06.000 --> 10:07.000 They can't 10:07.000 --> 10:09.000 So, in our 10:09.000 --> 10:12.000 Contiguous integration loop 10:12.000 --> 10:15.000 And so, we see F and I, middleware working or not 10:15.000 --> 10:18.000 But they are not used for anything useful today 10:18.000 --> 10:21.000 And, as other point is, they have no capabilities 10:21.000 --> 10:24.000 So, they have global strategies, global task 10:24.000 --> 10:27.000 Addies and all of them can try to pull each other 10:27.000 --> 10:28.000 And there is no protection 10:28.000 --> 10:31.000 So, Gnode cannot do anything against that 10:31.000 --> 10:33.000 But, of course, we abstract it the way 10:33.000 --> 10:36.000 So, if you do not try hard to convince it 10:36.000 --> 10:40.000 And you will not see the effect 10:40.000 --> 10:43.000 The second part is smaller 10:43.000 --> 10:45.000 I quoted modern kernels 10:45.000 --> 10:48.000 That's the one which I have capabilities to put 10:48.000 --> 10:51.000 Build in 10:51.000 --> 10:53.000 So, it started with a NOVA kernel 10:53.000 --> 10:55.000 Which is developed by Udo 10:55.000 --> 10:57.000 This version actually, but 10:57.000 --> 11:00.000 It is a heavily adjusted version to Gnode 11:00.000 --> 11:03.000 So, it is not a original version of Udo 11:03.000 --> 11:05.000 Then, it is a Fiasco C kernel 11:05.000 --> 11:07.000 Which also started in the university 11:07.000 --> 11:08.000 And now it is maintained 11:08.000 --> 11:10.000 Or developed further by can concept 11:10.000 --> 11:13.000 And, HW is a kernel 11:13.000 --> 11:15.000 Which is developed by Gnode Labs 11:15.000 --> 11:19.000 Which is specifically built for for Gnode 11:19.000 --> 11:22.000 And, also SLFO is supported 11:22.000 --> 11:26.000 Which as soon as it got open source 11:26.000 --> 11:28.000 It was popularly beforehand 11:28.000 --> 11:30.000 The added support 11:30.000 --> 11:34.000 At why to come with a characteristic metrics 11:34.000 --> 11:37.000 The main points here are 11:37.000 --> 11:40.000 Dynamic memory management for the kernel 11:40.000 --> 11:43.000 And towards user for SLFO 11:43.000 --> 11:46.000 And HW looks okay 11:46.000 --> 11:49.000 But, for HW it is much, much simpler 11:49.000 --> 11:50.000 Interfacing and for SLFO 11:50.000 --> 11:52.000 It's horrible complicated 11:52.000 --> 11:55.000 And, also the kernels have different ideas 11:55.000 --> 11:58.000 About whether they have one big kernel lock 11:58.000 --> 12:02.000 And, bringing the kernel to the kernel 12:02.000 --> 12:05.000 Supported with Gnode 12:05.000 --> 12:09.000 It's actually just a personal spare time project of mine 12:09.000 --> 12:12.000 So, there is no no project behind it 12:12.000 --> 12:14.000 Or funding or anything 12:14.000 --> 12:16.000 It's a very low priority 12:16.000 --> 12:18.000 I work on it 12:18.000 --> 12:21.000 Evening one to two hours as time fits 12:21.000 --> 12:23.000 It's like since eight months 12:23.000 --> 12:24.000 I'm looking on it 12:24.000 --> 12:26.000 My personal goal is that it's actually 12:26.000 --> 12:29.000 Easy-can-test current upstream version 12:29.000 --> 12:32.000 One of those also may ask 12:32.000 --> 12:33.000 Just the minor update 12:33.000 --> 12:35.000 Why it rebates and you are done 12:35.000 --> 12:36.000 No, actually not 12:36.000 --> 12:39.000 As I said, we have added features 12:39.000 --> 12:41.000 For example, like the Crosco IPC support 12:41.000 --> 12:43.000 Which is 12:44.000 --> 12:47.000 It's not easy to add again 12:47.000 --> 12:49.000 And I don't think so 12:49.000 --> 12:51.000 I wanted to do it again 12:51.000 --> 12:54.000 And so, in that sense, Gnose version 12:54.000 --> 12:56.000 As is now fixed 12:56.000 --> 12:59.000 Good enough to Gnode framework 12:59.000 --> 13:02.000 And we don't add new features 13:02.000 --> 13:05.000 It's only need to do need basis 13:05.000 --> 13:07.000 In contrast, the up stream 13:07.000 --> 13:08.000 The new one kernel is of course 13:08.000 --> 13:11.000 Under active development has a lot of features 13:11.000 --> 13:14.000 And also in our area of trust in computing 13:14.000 --> 13:16.000 So there's a presentation 13:16.000 --> 13:18.000 From UTO, from Celeste Phostems 13:18.000 --> 13:21.000 And of course, this kernel is actually 13:21.000 --> 13:23.000 An kernel which undergoes verification 13:23.000 --> 13:24.000 It's the plus plus 13:24.000 --> 13:26.000 We like the plus plus etchinode 13:26.000 --> 13:28.000 So maybe use this connection 13:28.000 --> 13:31.000 And I need a working title 13:31.000 --> 13:34.000 So base nova is already used 13:34.000 --> 13:35.000 So I need another name 13:35.000 --> 13:37.000 So I added CE as for some moment 13:37.000 --> 13:39.000 Experimental version 13:39.000 --> 13:44.000 But also the plural of having several nova instances 13:44.000 --> 13:47.000 So working items 13:47.000 --> 13:50.000 It's kind of easy 13:50.000 --> 13:53.000 Make a copy of the original repository 13:53.000 --> 13:55.000 Remove everything we added 13:55.000 --> 13:59.000 Since 2012 to the Gnode version 13:59.000 --> 14:01.000 We had this number 14:01.000 --> 14:03.000 Then you have to get the core running 14:03.000 --> 14:05.000 You have to refuse the documentation 14:05.000 --> 14:07.000 It's a specification which is quite good 14:07.000 --> 14:08.000 Adjusting also 14:08.000 --> 14:09.000 Cisco bindings 14:09.000 --> 14:10.000 Get hold of the major capabilities 14:10.000 --> 14:13.000 That you actually can make some 14:13.000 --> 14:15.000 Output that you can debux 14:15.000 --> 14:17.000 Sing that you get access to some 14:17.000 --> 14:19.000 Mighty boot, serve structure 14:19.000 --> 14:20.000 So that you can fill other 14:20.000 --> 14:22.000 Allocators in the root task 14:22.000 --> 14:24.000 The timer server 14:24.000 --> 14:26.000 So we'll need some slightly adjustment 14:26.000 --> 14:28.000 Because 14:28.000 --> 14:31.000 Waiting for IRQ is a blocking call 14:31.000 --> 14:33.000 On this nova version 14:33.000 --> 14:35.000 I had to re-ad IRQ scripts 14:35.000 --> 14:38.000 We have nodes in the Gnode version 14:38.000 --> 14:43.000 In order to play with real nice stuff 14:43.000 --> 14:45.000 So running all the test scenarios 14:45.000 --> 14:47.000 I also had to package everything 14:47.000 --> 14:50.000 Because nowadays we are using packages 14:50.000 --> 14:52.000 Even for simple test 14:52.000 --> 14:55.000 So fun part starts as soon as you start 14:55.000 --> 14:56.000 The second task 14:56.000 --> 14:58.000 And when you are looking at the 14:58.000 --> 14:59.000 Opposive framework 14:59.000 --> 15:01.000 So as I said in the beginning 15:01.000 --> 15:02.000 We want to delegate 15:02.000 --> 15:04.000 During an RPC or Gnode 15:04.000 --> 15:05.000 Also capabilities 15:05.000 --> 15:08.000 There is example definition 15:08.000 --> 15:10.000 This is not possible anymore 15:10.000 --> 15:12.000 This is coming 15:12.000 --> 15:13.000 This is what not to surprise 15:13.000 --> 15:15.000 Udo already announced 15:15.000 --> 15:16.000 Just go 15:16.000 --> 15:18.000 And 15:18.000 --> 15:19.000 Of course 15:19.000 --> 15:21.000 There is a source course 15:21.000 --> 15:22.000 Where you can delegate 15:22.000 --> 15:24.000 Cavalty but you have to have the target 15:24.000 --> 15:27.000 Cavalty of the guy where you want to push 15:27.000 --> 15:28.000 The Cavalty 15:28.000 --> 15:31.000 And those information are only available to poor 15:32.000 --> 15:34.000 And moving this ability 15:34.000 --> 15:37.000 I was an option from the Gnode perspective 15:37.000 --> 15:40.000 So what have to be done 15:40.000 --> 15:43.000 This task is already in the context of a NASA 15:43.000 --> 15:45.000 That we need some re-wouting service 15:45.000 --> 15:46.000 We are also good task 15:46.000 --> 15:47.000 We are a core 15:47.000 --> 15:49.000 And what is now happening is 15:49.000 --> 15:51.000 When ever the IPC framework sees 15:51.000 --> 15:53.000 That the capability must be delegated 15:53.000 --> 15:54.000 It will in the first step core 15:54.000 --> 15:56.000 Core will remember the fact 15:56.000 --> 15:58.000 Which capabilities should go to whom 15:58.000 --> 16:00.000 Returns in second step 16:00.000 --> 16:02.000 So that is actually IPC 16:02.000 --> 16:04.000 The multiplex on that case 16:04.000 --> 16:06.000 The coding tool 16:06.000 --> 16:07.000 So IPC definition 16:07.000 --> 16:09.000 I should have received 16:09.000 --> 16:10.000 A capability 16:10.000 --> 16:12.000 He will call 16:12.000 --> 16:13.000 Into core 16:13.000 --> 16:14.000 We ask for 16:14.000 --> 16:16.000 Please delegate the capability to me 16:16.000 --> 16:18.000 And then the IPC is done 16:18.000 --> 16:20.000 It is a fifth step 16:20.000 --> 16:22.000 Obviously this becomes more expensive 16:22.000 --> 16:24.000 If you are doing it often enough 16:24.000 --> 16:26.000 So 16:26.000 --> 16:27.000 That is already all 16:27.000 --> 16:29.000 Some time to 16:29.000 --> 16:31.000 Support 16:31.000 --> 16:32.000 Fiasco 16:32.000 --> 16:34.000 See it is a problem 16:34.000 --> 16:35.000 Obviously 16:35.000 --> 16:37.000 Officially supported 16:37.000 --> 16:39.000 He had to be 16:39.000 --> 16:41.000 I had to do something 16:41.000 --> 16:42.000 Fix-ups 16:42.000 --> 16:44.000 And now for the demo 16:44.000 --> 16:45.000 Quite looking quite good 16:45.000 --> 16:47.000 I uploaded an image in case you are interested 16:47.000 --> 16:49.000 And actually 16:49.000 --> 16:51.000 I wanted to demonstrate this live 16:51.000 --> 16:52.000 Free-booning 16:52.000 --> 16:53.000 So machine 16:53.000 --> 16:55.000 I think I will not have enough time 16:56.000 --> 16:57.000 But 16:57.000 --> 16:59.000 I have something else 16:59.000 --> 17:01.000 Instead I decided to make 17:01.000 --> 17:02.000 The whole demo 17:02.000 --> 17:03.000 Once it is kept 17:03.000 --> 17:04.000 Cool 17:04.000 --> 17:05.000 And 17:05.000 --> 17:07.000 When you boot this image 17:07.000 --> 17:08.000 You will see 17:08.000 --> 17:09.000 In the white button 17:09.000 --> 17:11.000 On which tunnel you are 17:11.000 --> 17:12.000 Cool 17:12.000 --> 17:14.000 You are not getting confused 17:14.000 --> 17:15.000 And if you don't believe 17:15.000 --> 17:17.000 The pixels in the white button 17:17.000 --> 17:19.000 I also had 17:19.000 --> 17:21.000 I have a lot of options 17:21.000 --> 17:23.000 We can look for the bootlock 17:24.000 --> 17:25.000 And 17:25.000 --> 17:27.000 Someone who 17:27.000 --> 17:28.000 Familiar with this 17:28.000 --> 17:29.000 Output of the tunnel 17:29.000 --> 17:30.000 Maybe 17:32.000 --> 17:33.000 Look 17:33.000 --> 17:34.000 That is a good idea 17:34.000 --> 17:35.000 Upstream version 17:35.000 --> 17:36.000 But 17:36.000 --> 17:37.000 Not like someone from 17:37.000 --> 17:38.000 2012 17:38.000 --> 17:39.000 From the Output 17:39.000 --> 17:40.000 So 17:40.000 --> 17:41.000 Okay, I said 17:41.000 --> 17:42.000 Or 17:42.000 --> 17:43.000 Or 17:43.000 --> 17:44.000 Or 17:44.000 --> 17:45.000 Or 17:45.000 --> 17:46.000 Or 17:46.000 --> 17:47.000 Or 17:47.000 --> 17:48.000 Or 17:48.000 --> 17:49.000 Or 17:49.000 --> 17:50.000 Or 17:50.000 --> 17:51.000 Or 17:51.000 --> 17:52.000 I know 17:52.000 --> 17:53.000 Ouch 17:53.000 --> 17:55.000 fr Therefore 17:55.000 --> 17:56.000 But 17:56.000 --> 17:57.000 Or 17:57.000 --> 17:58.000 Wrong 17:58.000 --> 17:59.000 Or 17:59.000 --> 17:59.100 Right 17:59.100 --> 18:00.000 And 18:01.000 --> 18:02.000 Yep 18:02.000 --> 18:03.000 Or 18:03.000 --> 18:04.100 Is 18:04.100 --> 18:05.000 Of course 18:05.000 --> 18:06.000 Or 18:06.000 --> 18:09.000 Or 18:09.000 --> 18:10.000 Perhaps 18:10.000 --> 18:11.000 Or 18:11.000 --> 18:12.000 If 18:12.000 --> 18:13.000 Or 18:13.000 --> 18:14.000 Or 18:14.000 --> 18:15.000 Or 18:15.000 --> 18:19.020 Or 18:19.020 --> 18:23.460 Let's have Mesa Gears running, hopefully. 18:35.220 --> 18:38.460 So this is a this GPU support. 18:39.740 --> 18:44.740 Yes, that's actually all I wanted to show you. 18:47.380 --> 18:48.700 Yeah, thank you for your attention. 18:49.260 --> 18:50.260 Thank you. 18:56.540 --> 19:00.780 All right, I'm quite happy to hear that you're working on the global version. 19:01.500 --> 19:07.540 Do we have any of obviously, I'll try my best to help you overcome some of these challenges? 19:07.540 --> 19:08.180 That's nice. 19:08.180 --> 19:09.020 Yeah. 19:09.020 --> 19:11.780 So how do we have any questions from you to do in the audience? 19:12.980 --> 19:14.780 Thanks for your presentation. 19:14.780 --> 19:15.900 What do you do? 19:16.540 --> 19:17.940 You're going to set up on this top. 19:21.620 --> 19:24.740 As the question was, what's my debugging set up? 19:24.740 --> 19:27.900 How I could proceed or can get back to this? 19:28.860 --> 19:33.580 Actually, also I have done because as X86, I can just do it in KOMU. 19:33.580 --> 19:35.660 So it's no no deal. 19:36.220 --> 19:40.100 And because I also have the current lower version and the new one, 19:40.100 --> 19:44.220 I can also compare where the difference in the output and so where I have 19:44.300 --> 19:45.460 done something wrong. 19:45.460 --> 19:47.660 So let's quite comfortable in set. 19:52.540 --> 19:52.940 Yes. 19:55.340 --> 19:55.900 That's possible. 19:57.980 --> 19:58.700 Any other questions? 20:01.100 --> 20:02.300 Yes, of question over there. 20:04.380 --> 20:07.100 Now, some may be there for some of you to make more fine parts. 20:07.100 --> 20:08.220 I'm missing a big picture. 20:08.740 --> 20:12.180 The same implies that this is comfortable. 20:19.820 --> 20:20.580 Yes, yes. 20:32.060 --> 20:37.220 I don't know what I can do. 20:37.220 --> 20:40.220 Can you please shorten your question? 20:40.220 --> 20:44.220 What's in between the memory, the linear browser, the model browser? 20:44.220 --> 20:45.220 Yeah. 20:45.220 --> 20:46.220 Oh, come to the operation. 20:46.220 --> 20:50.220 And a very, very simple question. 20:50.220 --> 20:53.220 So, China framework? 20:53.220 --> 20:55.220 No. 20:55.220 --> 21:00.220 I am, as Greshmos, what is the paper between the...