| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> Hi Claunia
<1> jwessel: Claunia is interested by having as many OSes as possible running on QEMU ppc
<2> and on QEMU x86 and on QEMU Sparc and on QEMU MIPS and on QEMU ARM and on QEMU <put your favourite ugly word here>
<0> I would like to see that too.
<2> xD
<1> jwessel: did you begin to look at OpenBIOS N
<1> ?
<0> I did.
<0> I ported about 1/2 of it.
<0> To PPC.
<0> I still had some ***embly level bring up yet to do.
<1> good
<0> It is close to a stage where I was going to send off some patches to OpenBios folks.
<3> hiho :)
<3> I just wanted to ask when kqemu will be open source
<3> is there a specific date planned?
<3> it would be great because kqemu could then be integrated in the official kernel
<1> Currently I have no plans to make it open source and I am not sure it would be accepted in the Linux kernel !
<1> althought having a syscall to virtualize the x86 CPU would be good (a little like vm86)
<3> hi Fabrice :)
<3> hint, are you sure?
<3> does it have a bad code quality?
<1> I never said the quality of the code is bad
<1> personnaly I like it :-)
<3> you said "I am not sure it would be accepted in the Linux kernel"
<3> I think you have a reason for that meaning ;)
<1> it is just that it is difficult to make patch accepted in the kernel
<3> hmm
<1> moreover, the code is complicated to validate and it would be seen as a source of security problems
<3> I think that should be no problem
<3> if you write to the official kernel mailing list that you want to open source the kqemu module than at least 2 or 3 persons will be there who write the patch and commit it :)
<3> hint: is it mostly ***embler code?
<3> or C?
<1> mostly C code
<3> what do you mean with security problems?
<1> in complicated code there are always bugs hence security problems
<1> and instability
<3> yes
<3> of course
<3> but there are just some actions to fix this
<3> like: at first, /dev/kqemu is only available for "root" - and for users which are in the group "kqemu"
<1> right
<3> what is the main problem that you do not want to free kqemu?
<3> money?
<2> it is a good reason
<2> whatever
<1> money
<1> as long as I can earn money with kqemu it won't be opened sourced
<3> do you earn money with it?
<3> regulary?
<4> i doubt there would be interest in kqemu in the kernel...
<4> something like qvm86 that used vt/svm.. probably
<3> aliguori: do you?
<1> aliguori: I agree
<3> hint: what would be the amount of money for that you will free kqemu?
<3> ;)
<1> a few M$
<4> marcreichelt, you have to make a darn compelling case to add complexity to the kernel.. and people are just going to say, why bother when you can use vt/svm
<2> xD
<3> hmm
<1> aliguori: unfortunately the main complexity in someting like kqemu or qvm86 is the memory handling and VT does not simplify the code
<5> Pacifica does afaik
<1> aliguori: so the solution to integrate in the kernel would be to use the memory management of the processes
<4> it's an optional feature
<4> that AFAIK doesn't exist in any current hardware
<4> hint, you mean the shadow paging code? or are you talking about memory allocation?
<5> really? i thought that hardward "shadow page table" management was part of the base specification.
<4> filip2307, as an optional feature
<5> even on Pacifica?!
<5> hm
<1> aliguori: shadow paging
<5> i should read it again before talking :)
<4> filip2307, intel has another that future versions of VT will include hardware shadow paging too
<4> hint: yeah, shadow paging is a beast, but there's enough reference implementations floating around by now
<4> hint: there is also, of course, the problem with 16 bit code in VT
<4> that would complicate a kernel module
<5> yeah, i know that the current VT doesn't have it and it was promised, but the preliminary specifications of SVM had it listed as one of the main features, so i didn't expect it to be optional :/
<1> if it was in the Linux kernel I guess it would be better to implement only things supported by the hardware
<3> Fabrice, for which amount of money would you open source kqemu?
<1> no less than 100 k euros
<3> oh
<3> k
<4> filip2307, if nothing else, when hardware does become available publicly you'll see much ado on the xen lists about it :-)
<4> we've been waiting for a long time to see what the relative performance is going to be between hardware/software nested paging
<3> hmm
<3> that's quite too much
<5> it's a fair price for such code.
<3> filip2307: really?
<1> marcreichelt: I don't think it is a too high price
<3> you must know it, because you created it :)
<3> but because kqemu is closed source it will never be used that much
<4> that's nothing compared to the cost of getting it into the kernel :-)
<5> marcreichelt, it may sound a bit high, but there are only few experts in this field ...
<3> k
<4> marcreichelt, consider how hard of a time xen is having... kqemu would be far worse
<5> (not to mention that driver development by itself is paid VERY good. too bad i'm not in that business anymore ;-)
<3> but in my eyes, it would be better to free kqemu for less money (e.g. 10 k euros) and _many_ people using it
<1> marcreichelt: anyway, I can always change my mind. But it won't be freed in the next few months
<3> do you have a job, or is kqemu the (nearly) only way for you to earn money?
<1> I have a job
<3> I thought so, because if you are able to write kernel C code you must be competent enough to get a job in every company :)
<3> (hmm, maybe I should write my own /dev/helloworld device ;)
<5> every company? McDonalds was the first one that came to my mind ... :X :)
<3> lol
<4> hint: i'm working on a very simple gui for qemu. one of the things i'm doing different than the sdl one is putting all the VC is tabs of a notebook with a terminal widget. it appears, however, the monitor doesn't spit out proper newlines (it spits out \n, not \r\n)
<3> filip2307, of course I mean big IT companies with a great income, and not the little-fastfood-restaurant-around-the-corner ;)
<4> which is fine when printing to stdio, but when coming from a pty, it confuses terminal emulators
<3> or the big-fastfood-restaurant-around-the-corner
<3> whatever
<3> hmm
<3> /dev/mcdonalds
<4> hint: i can see two solutions, make term_printf() do newline translation or just hack around it on my end
<3> *g*
<6> aliguori, cant you turn on onlcr on a pty too?
<4> nox-, that's a good idea
<5> marcreichelt, i know, just the idea of kernel C coder serving me a hamburger came through my mind ... nvm
<1> aliguori: strange. The internal QEMU terminal should have the same problem
<3> I must leave now, some friends wait for me
<2> hint, you have more right than me to be up
<1> Claunia: thanx!
<2> don't be a bad guy!
<2> see ya folks
<0> aligori, in the latest patch I sent, I have the term_printf() patched up.
<2> going to dream in pretty and girly thinks it seems xD
<5> cya ;)
<5> 'n'have fun :)
<3> yeah, ciao
<5> marcreichelt, i used to be an optimist too :)
<3> used?
<3> so you are a pessimist now? ;)
<2> marcreichelt, hey! it's me who will dream, not you! xD
<5> though i'm not sure i'd like to see the hacks used by the graphics drivers...
<5> nope, no way, i'm realist :)
<3> k
<3> bye
<1> aliguori: OK I see the problem now. The QEMU console does not interpret correctly '\n'. So the console must be patched and '\r' must be added in term_puts
<0> hint: I faced the same problem with telnet.
<0> Telnet needs the \n\r
<0> Which is why I patched it in the mux patch.
<4> jwessel you mean \r\n?
<0> Yes.
<0> Actually I have it as \n\r
<0> Do I have it backwards...
<0> Nope. \r == ^M
<7> \r comes first
<4> it doesn't matter
Return to
#qemu
or
Go to some related
logs:
#perl
#mysql
#fedora
rtsp cloakport mplayer
artsdsp works only for binaries
backtrack broadcom bcm43xx
diamondback evdev
#ubuntu
#ubuntu
#kde
|
|