On Sunday, November 24, 2019 at 2:13:02 PM UTC-5, Nadav Har'El wrote: > > On Tue, Nov 12, 2019 at 12:49 AM Waldek Kozaczuk <jwkoz...@gmail.com > <javascript:>> wrote: > >> First of OSv comes with a simple VGA console driver that allows apps like >> rogue run (see apps/rogue). >> >> As far as X11 apps I had not tried to run them before you asked so I had >> no idea they would work. So I actually spent some time playing with some of >> the simple ones and I got many of those to function on OSv after applying a >> small patch which I show later. I tried the following apps: xclock, xeyes, >> xlogo, xcalc and they seemed to work after I configured my host - Ubuntu >> 19.04 - to accept X11 connections over TCP (which is slower than local >> socket - I wonder it vsock would work better here) and let unauthorized >> traffic using xhost+. >> > > Cool :-) > > We could have an example xeys application in apps.git, using TCP (and > xauth - better not use "xhost +" - not even for tests). > > >> Running chrome I think would be more complicated as it uses GPU >> acceleration (you can disable it though) and more importantly forks itself >> for each open tab and OSv does not support fork(). New virtio 1.1 spec >> defines GPU device but I am not sure how well supported it is and somebody >> would need to implement the driver for OSv, >> > > I don't know what you mean by "GPU acceleration" - if chrome *can *work > over regular old-style X Windows without any bypassing attempts, it will > also work in this setup. > Also according to > https://www.chromium.org/developers/design-documents/process-models you > can ask for a "single process" mode and supposedly not need fork(). > > But we have to face the harsh reality, that the bigger an application is, > the higher the chances that it uses some obscure feature which OSv doesn't > implement yet. > So even if xeyes and xlogo work, there's a significant chance that chrome > won't. > And of course, if chrome uses fork(), > > >> Here is a hacky patch to the networking layer (I need to understand why >> this assert fails): >> >> diff --git a/bsd/sys/compat/linux/linux_socket.cc >> b/bsd/sys/compat/linux/linux_socket.cc >> index c1bbc496..09c5bed6 100644 >> --- a/bsd/sys/compat/linux/linux_socket.cc >> +++ b/bsd/sys/compat/linux/linux_socket.cc >> @@ -1081,7 +1081,7 @@ linux_recvmsg(int s, struct msghdr *msg, int flags, >> ssize_t* bytes) >> goto bad; >> } >> >> - assert(msg->msg_controllen == 0); >> + //assert(msg->msg_controllen == 0); >> assert(msg->msg_control == NULL); >> >> #if 0 >> >> > I think we never properly implemented the "ancillary data" (control > message) feature of sockets which can be used to, among other things, send > an open file descriptor between two processes communicating over a > UNIX-domain socket. I don't remember why we never implemented this - I > think the problem was (considering the file this is in, > compat/linux/linux_socket.cc) that the BSD-based code assumes this > ancillary data has one structure, but the Linux API assumes a different > structure. Unfortunately this will be hard to fix properly without looking > at the code and at the socket manual pages, and trying to remember what the > heck this code is supposed to be doing. I also see there's a lot of #if 0 > code in this area :-( > > Perhaps we can take a patch which doesn't outright remove these asserts, > but just replaces them by a WARN_ONCE or something, so we'll allow these > control messages but warn that they may not be handled properly. > That sounds like a good idea. I will send a patch at some point.
> > >> >> >> If you are are interested in more details on how to try some of the apps >> let me know. >> > > If you could create a working example in apps.git, people could refer to > it later. > Sure. > > >> Waldek >> >> On Sunday, November 10, 2019 at 5:23:53 AM UTC-5, Sudhakar RS wrote: >>> >>> >>> TIA. Is it possible to run apps like chrome as OSv Unikernels and >>> forward X11 to the Host OS?. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "OSv Development" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to osv...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/osv-dev/3cd2b0ce-fe2a-4992-b489-a65a1e866f3b%40googlegroups.com >> >> <https://groups.google.com/d/msgid/osv-dev/3cd2b0ce-fe2a-4992-b489-a65a1e866f3b%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/78e0be9e-ba66-41a8-8413-f112e32453dd%40googlegroups.com.
