* Re: [Qemu-devel] VNC terminal server?
From: Leonardo E. Reiter @ 2006-04-08 19:33 UTC (permalink / raw)
To: balrogg, qemu-devel
In-Reply-To: <fb249edb0604081221w1228728hc7c885892d9da7de@mail.gmail.com>
The Win4Lin Pro version is not a driver, but rather a high-priority
Windows userspace thread. We try to avoid drivers as much as possible
because they are a serious obstacle to supporting new Windows versions
and service packs as they come out. I can't comment on VMware's
approach to be honest.
I will say that using a device that has readily and/or publicly
available drivers is probably ideal, such as a Wacom tablet. We are
trying to move to more of a device model on Win4Lin Pro for performance
reasons, which is why I am interested in this approach. But letting
Microsoft maintain the guest driver, if it's built into Windows, is the
best solution. It also guarantees the broadest possible guest support
in general - whether it be Linux, Mac OS X, etc.
If anyone has a link to Anthony Liguori's driver, I'd be glad to look
into fixing whatever may be wrong with it and posting the patches.
Thanks,
Leo Reiter
andrzej zaborowski wrote:
> I thought Anthony Liguori had already written a Wacom tablet emulator
> for QEMU and that worked fine except it supports only one button. I
> don't remember if this support was complete and I don't have a link to
> the patch.
>
> With this you don't need to disable mouse acceleration in the guest OS
> because it makes no sense to accelerate a tablet.
>
> On the other hand writing a guest-side driver for QEMU would leave
> room for further improvements like hiding/showing or
> grabbing/releasing the mouse at specific moments. Or, possibly reusing
> tools from Win4Lin or VMtools from VMware.
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Jim C. Brown @ 2006-04-08 19:30 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082112030.8325@wbgn013.biozentrum.uni-wuerzburg.de>
On Sat, Apr 08, 2006 at 09:12:18PM +0200, Johannes Schindelin wrote:
> > Anthony Ligouri has written a patch for wacom support.
> >
> > However, when I combine this with the -no-sdl-grab patch I still see syncing
> > issues.
>
> Where can I get it?
http://www.cs.utexas.edu/users/aliguori/qemu-wacom-2.tgz
>
> Ciao,
> Dscho
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply
* today news
From: Gopal Prowell @ 2006-04-08 19:28 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1: Type: text/plain, Size: 245 bytes --]
A
V
X
C
P
V
L
m
A
a
I
r
I
e
b
L
n
A
o
A
v
i
I
a
L
z
G
i
e
U
x
I
a
R
t
n
M
S
c
A
r
a
http://www.anitaroun.com <http://www.anitaroun.com>
[-- Attachment #2: Type: text/html, Size: 1688 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] Unified device model
From: Jim C. Brown @ 2006-04-08 19:28 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082116540.8530@wbgn013.biozentrum.uni-wuerzburg.de>
On Sat, Apr 08, 2006 at 09:17:52PM +0200, Johannes Schindelin wrote:
> IIRC bochs does it in C++. Which makes it rather impossible to share code
> :-(
>
> Ciao,
> Dscho
>
This is why I guessed qemu was a rewrite-from-scratch - C++ code is forbidden
in qemu.
Fortunately this does not prevent a properly designed binary plugin API.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply
* Re: [Qemu-devel] Unified device model
From: Leonardo E. Reiter @ 2006-04-08 19:27 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082116540.8530@wbgn013.biozentrum.uni-wuerzburg.de>
Well, not completely impossible, but it would require some really ugly
"glue" code. And, the glue would have to happen outside of QEMU (i.e.
like in the BOCHS code), to keep C++ out of QEMU.
To have a truly portable API, it should definitely have C language
"bindings". I'm sure this could be added to the BOCHS implementation
somehow if this is important.
- Leo Reiter
Johannes Schindelin wrote:
> IIRC bochs does it in C++. Which makes it rather impossible to share code
> :-(
>
> Ciao,
> Dscho
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
^ permalink raw reply
* Re: Page Migration: Make do_swap_page redo the fault
From: Hugh Dickins @ 2006-04-08 19:26 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linux-mm
In-Reply-To: <Pine.LNX.4.64.0604081058290.16914@schroedinger.engr.sgi.com>
On Sat, 8 Apr 2006, Christoph Lameter wrote:
>
> Hmmm..,. There are still two other checks for !PageSwapCache after
> obtaining a page lock in shmem_getpage() and in try_to_unuse().
> However, both are getting to the page via the swap maps. So we need to
> keep those.
Sure, those are long standing checks, necessary long before migration
came on the scene; whereas the check in do_swap_page was recently added
just for a page migration case, and now turns out to be redundant.
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Problem installing K3b into suse7.3-sparc
From: Donald Parsons @ 2006-04-08 19:24 UTC (permalink / raw)
To: sparclinux
Hello!
I am trying to install one or other of the update binaries of k3b and
getting similar failures with each.
My attempts to compile the sources have also not been successful.
There seems to be insufficient suse-sparc files to patch up the install.
After installing rpm k3b-0.9-3.sparc.rpm I get:
dfp10@paxultra:/opt/kde3/bin> ./k3b
kio (KSycoca): WARNING: Found version 40, expecting version 61 or higher.
kio (KSycoca): WARNING: Outdated database found
kio (KSycoca): WARNING: Found version 40, expecting version 61 or higher.
kio (KSycoca): WARNING: Outdated database found
k3b: WARNING: KDE detected X Error: BadMatch (invalid parameter attributes)
\x08
Major opcode: *
kio (KSycoca): WARNING: Found version 40, expecting version 61 or higher.
kio (KSycoca): WARNING: Outdated database found
k3b: WARNING: KDE detected X Error: BadMatch (invalid parameter attributes)
\x08
Major opcode: *
dfp10@paxultra:/opt/kde3/bin> rpm -q k3b
k3b-0.9-3
Also, on the screen:Could not find mime type: application/octet-stram
no Mime Types installed!
Could someone give me assistance with this?
Thanks
Donald Parsons
dfp10@capital.net
^ permalink raw reply
* Re: [RFC: 2.6 patch] the overdue removal of RAW1394_REQ_ISO_{LISTEN,SEND}
From: Dan Dennedy @ 2006-04-08 19:18 UTC (permalink / raw)
To: linux1394-devel; +Cc: Stefan Richter, Adrian Bunk, scjody, linux-kernel
In-Reply-To: <44374FC0.3070507@s5r6.in-berlin.de>
On Friday 07 April 2006 22:53, Stefan Richter wrote:
> Adrian Bunk wrote:
> > This patch contains the overdue removal of the RAW1394_REQ_ISO_SEND and
> > RAW1394_REQ_ISO_LISTEN request types plus all support code for them.
>
> [...]
>
> I am not familiar with the isochronous part of Linux' 1394 software
> stack, so I can't comment whether there are high-profile applications
> which still did not migrate away from this interface, or did so only
> recently.
Kino still uses the legacy raw1394 iso interface for capture by default;
however, it can also still use dv1394. I will accellerate the adoption of the
new raw1394 interface since I have already done this for dvgrab 2.0.
Cinelerra supports libiec61883 now.
Unfortunately, gstreamer still uses legacy raw1394 iso interface, but I can
nag someone at Fluendo. I think another high profile app that might be
affected is GnomeMeeting/Ekiga, but I have not kept close track of it.
Also, I have not released a version of libraw1394 that contains the
deprecation warnings, but I can do so this weekend. And then another release
when the removed kernel interfaces are released that removes the functions.
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: andrzej zaborowski @ 2006-04-08 19:21 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082003380.7783@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
> IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse
> support is rather flakey: You have to disable mouse acceleration of the
> guest OS.
>
> I had that cunning plan to write a virtual Wacom tablet, but I just don't
> find the time.
>
I thought Anthony Liguori had already written a Wacom tablet emulator
for QEMU and that worked fine except it supports only one button. I
don't remember if this support was complete and I don't have a link to
the patch.
With this you don't need to disable mouse acceleration in the guest OS
because it makes no sense to accelerate a tablet.
On the other hand writing a guest-side driver for QEMU would leave
room for further improvements like hiding/showing or
grabbing/releasing the mouse at specific moments. Or, possibly reusing
tools from Win4Lin or VMtools from VMware.
> Ciao,
> Dscho
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
--
balrog 2oo6
Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258
^ permalink raw reply
* Re: [Qemu-devel] Unified device model
From: Johannes Schindelin @ 2006-04-08 19:17 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20060408191219.GB16963@jbrown.mylinuxbox.org>
Hi,
On Sat, 8 Apr 2006, Jim C. Brown wrote:
> On Sat, Apr 08, 2006 at 09:57:10PM +0200, Stanislav Shwartsman wrote:
> >
> > It is not a secret that all open source emulators (QEMU, Bochs, Xen) use the
> > same emulated devices and mostly copy-paste their emulation one from
> > another.
>
> While from my understanding Xen uses qemu's hardware emulation for it's VT
> support, this is not really true otherwise.
>
> The devices emulated by qemu and bochs are quite similar, but the code looks
> completely different (appears to be a ground-up rewrite).
IIRC bochs does it in C++. Which makes it rather impossible to share code
:-(
Ciao,
Dscho
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Leonardo E. Reiter @ 2006-04-08 19:15 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082054320.8169@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Frankly, I do not know if they are free. But as nobody pays me to play
> with QEmu, I do not care about Windows so much. And the Wacom drivers for
> Linux are free.
Yes, I understand. I've been looking at the XFree86 version of the
driver already. Unfortunately any time I spend on this will have to
apply to Windows guests as well, as you can imagine. My company sells
Windows-on-Linux software that uses QEMU, so it has to play with Windows
guests ;) In fact, there was a recent PS/2 mouse patch on this list and
a hack for XFree86 which was very simple. I didn't try it, but if you
are using Linux guests you can probably get absolute positioning very
easily. I don't recall who posted the patch - it was recent. The fix
for the guest X server is very simple as well.
>
> BTW I prefer a virtual wacom tablet to Summagraphics, since kudzu (the
> hardware detection which is used in Knoppix) can detect it. Unfortunately
> just the USB version :-(
Yes, given the state of USB in QEMU it's probably best to stick to
serial for now if you want something that works very reliably and soon.
Serial would be my intention. The only issue may be how this plays
with Windows guests - again, this is very important to me.
> Wow! What an offer! I have some documentation somewhere, I just had a
> look, and only found the Summagraphics documentation. I will look harder.
Thanks!
> My favourite cartoonist, Jamiri, is very proud of his Wacom tablet. IIRC,
> it has an integrated LCD display. So, I assume absolute positioning is
> automatically switched on with that tablet.
I would think so too. But, in looking at the XFree86 version of the
driver, it's apparently configurable and my fear is that Windows will
flick it to relative mode so it can play acceleration tricks. But
anyway, it's worth investigating.
Actually Jim C. Brown just posted a note that there is an existing
patch, but I can't seem to find it. Jim, I'd be glad to look at it even
though you are saying that it is still flaky - perhaps it can be fixed.
Thanks,
Leo Reiter
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
^ permalink raw reply
* Re: [Qemu-devel] Unified device model
From: Jim C. Brown @ 2006-04-08 19:12 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <E1FSIdM-0002h4-18@lists.gnu.org>
On Sat, Apr 08, 2006 at 09:57:10PM +0200, Stanislav Shwartsman wrote:
> Hello All,
>
>
>
> It is not a secret that all open source emulators (QEMU, Bochs, Xen) use the
> same emulated devices and mostly copy-paste their emulation one from
> another.
While from my understanding Xen uses qemu's hardware emulation for it's VT
support, this is not really true otherwise.
The devices emulated by qemu and bochs are quite similar, but the code looks
completely different (appears to be a ground-up rewrite).
>
> I don't know who originally wrote the device models but now Bochs and QEMU
> maintain two similar implementations of the same devices.
>
> If one of the teams fixes the implementation or add functionality, another
> team mostly copy-paste the changes to their model.
I don't know how well Bochs and qemu keep in touch with each other. I've never
seen a Bochs developer announce themselves here, though.
>
> Xen project forked from QEMU and want to stay in touch with Bochs and QEMU
> device models and contribute the changes to make the model better.
Not true. Xen is completely independent. Unless you are refering to the
hardware emulation - which I believe is qemu's stuff.
>
> I am wondering about making unified device models architecture for open
> source simulators.
>
> The device models will be used in QEMU, Bochs, Xen and other open source
> simulators which would use the device models.
>
I would support this idea, if it was possible.
> I know about two professional teams working in simulation which would like
> to use these device models in their simulator and
>
> could enrich the device library with new devices device interfaces, for
> example with AGP and 3D graphics.
>
> Bochs is already in middle of definition of new true pluginable devices
> architecture.
>
This is welcome news.
> In near future Bochs devices will fully separatable from Bochs binary and
> when could be developed separately from Bochs.
>
> I call to QEMU developers join to this project and come with their
> requirements to plugin architecture.
>
> I don't know if QEMU supports device plugins now but I would like to see
> QEMU a part of this idea,
>
I would as well.
> I would like to get single device shared library which could be loaded to
> Bochs and QEMU and work perfectly for both.
>
> This will eliminate the need to maintain two separate implementations of the
> same devices,
>
> these implementations very fast will converge to single one, C or C++ based,
> Bochs or QEMU based, doesn't matter.
>
> I am listening for your opinions !
>
>
The primary reason given for not making a plugin API for qemu hardware emulation
is that qemu isn't stable enough - the code changes too often to support a stable
API.
Still, it might be easier to add support for plugins based on an external API,
rather than trying to keep a qemu plugin API consistent.
>
> Thanks,
>
> Stanislav
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Johannes Schindelin @ 2006-04-08 19:12 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20060408190115.GA16963@jbrown.mylinuxbox.org>
Hi,
On Sat, 8 Apr 2006, Jim C. Brown wrote:
> On Sat, Apr 08, 2006 at 08:24:03PM +0200, Johannes Schindelin wrote:
> > IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse
> > support is rather flakey: You have to disable mouse acceleration of the
> > guest OS.
> >
> > I had that cunning plan to write a virtual Wacom tablet, but I just don't
> > find the time.
> >
> > Ciao,
> > Dscho
> >
>
> Anthony Ligouri has written a patch for wacom support.
>
> However, when I combine this with the -no-sdl-grab patch I still see syncing
> issues.
Where can I get it?
Ciao,
Dscho
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Johannes Schindelin @ 2006-04-08 19:04 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <443802FB.9060700@win4lin.com>
Hi,
On Sat, 8 Apr 2006, Leonardo E. Reiter wrote:
> this virtual Wacom tablet you refer to... is there a [free or built-in]
> Windows 2000/XP driver associated with it that supports either no
> acceleration and/or absolute positioning?
Frankly, I do not know if they are free. But as nobody pays me to play
with QEmu, I do not care about Windows so much. And the Wacom drivers for
Linux are free.
BTW I prefer a virtual wacom tablet to Summagraphics, since kudzu (the
hardware detection which is used in Knoppix) can detect it. Unfortunately
just the USB version :-(
> If so, perhaps I can look at implementing it in QEMU in my "spare" time
> ;) Do you have a link to documentation and/or drivers?
Wow! What an offer! I have some documentation somewhere, I just had a
look, and only found the Summagraphics documentation. I will look harder.
> If the guest OS can't be easily told to not do any acceleration and/or
> use absolute cursor positioning rather than relative moves, it's not
> that helpful to have a new type of input device. I suspect a tablet
> driver can be easily configured this way since design people who
> probably use these devices want perfect precision between pointer and
> screen - otherwise they'd probably just use a mouse/trackball. But you
> can never be sure how Microsoft (or Wacom) decided to implement the
> Windows version of the driver.
My favourite cartoonist, Jamiri, is very proud of his Wacom tablet. IIRC,
it has an integrated LCD display. So, I assume absolute positioning is
automatically switched on with that tablet.
> The mouse sync solution we have in Win4Lin Pro is okay, but it's a bit
> slow and I'd like to do something much cleaner. Of course if I do the
> wacom tablet implementation, it will be open source and part of QEMU
> itself.
>
> Thanks!
Thank you!
Ciao,
Dscho
^ permalink raw reply
* Re: nfs over 2tb limitation
From: Trond Myklebust @ 2006-04-08 19:01 UTC (permalink / raw)
To: Julio Prada; +Cc: nfs
In-Reply-To: <E80C016468F5454E93FBC2FBF2F93AE47FB4F6@EINSTEIN.idg.idgrup.com>
On Fri, 2006-04-07 at 09:34 +0200, Julio Prada wrote:
> Hello,
>=20
> =20
>=20
> The scenario is a Hp clustered gateway that theorically can virtualize
> up to 16TB, and it seems that the limitation it=E2=80=99s on NFS client t=
hat
> only can reach up to 2TB on large filesystems.
Nope. That is completely wrong. The NFS client neither knows nor cares
about the size of your filesystem. If you have > 2TB accessible on the
server, then the client can and will use it.
What is true, though, is that if you compile without CONFIG_LBD (or
CONFIG_LSF on 2.6.17-rc1) then the statfs() and statvfs() system calls
will incapable of displaying more than 2TB.
IOW: 'df' will display some incorrectly small size.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Jim C. Brown @ 2006-04-08 19:01 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082003380.7783@wbgn013.biozentrum.uni-wuerzburg.de>
On Sat, Apr 08, 2006 at 08:24:03PM +0200, Johannes Schindelin wrote:
> IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse
> support is rather flakey: You have to disable mouse acceleration of the
> guest OS.
>
> I had that cunning plan to write a virtual Wacom tablet, but I just don't
> find the time.
>
> Ciao,
> Dscho
>
Anthony Ligouri has written a patch for wacom support.
However, when I combine this with the -no-sdl-grab patch I still see syncing
issues.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply
* slram
From: Antonio Di Bacco @ 2006-04-08 19:02 UTC (permalink / raw)
To: linuxppc-embedded
Anyone knows what slram driver is meant for?
Bye,
Antonio.
^ permalink raw reply
* Re: Regarding Wrapfs Code - function wrapfs_interpose
From: Erez Zadok @ 2006-04-08 19:00 UTC (permalink / raw)
To: Avishay Traeger; +Cc: UZAIR LAKHANI, linux-fsdevel
In-Reply-To: <1144501811.13374.13.camel@ool-44c32f98.dyn.optonline.net>
In message <1144501811.13374.13.camel@ool-44c32f98.dyn.optonline.net>, Avishay Traeger writes:
> On Fri, 2006-04-07 at 21:51 -0700, UZAIR LAKHANI wrote:
> > I want to find out the purpose of a part of Wrapfs
> > code.
> >
> > The function name is wrapfs_interpose
> >
> > The code is
> >
> > /* check that the lower file system didn't cross a
> > mount point */
> > if (lower_inode->i_sb != SUPERBLOCK_TO_LOWER(sb)) {
> > err = -EXDEV;
> > goto out;
> > }
> >
> > I want to find out what is the purpose of the above
> > check.
>
> Exactly what the comment says - it checks to make sure that we didn't
> cross a mount point. It does this by making sure that the lower-level
> superblock of this lower-level inode is the same as the lower-level
> superblock that we expect (the one used at mount-time). So basically,
> if we see a superblock that is different from the one we usually use, we
> crossed a mount point and so we return an error.
>
> Avishay Traeger
> http://www.fsl.cs.sunysb.edu/~avishay/
More detail.
In its default mode, Wrapfs generates inode numbers by inheriting the inum
of the lower inode: that way we are guaranteed unique inodes, and a fast
operation to generate inodes. But if you cross into a new sb, you could
clash with other inodes that have the same inum (confusing the icache) -- so
the default alg doesn't work unless we prohibit you from crossing into lower
sb's.
Wrapfs supports therefore another mode in which we use iunique() to generate
unique inums. In this mode you *can* cross into new sb's, but the
disadvantage now is that your inums are not persistent (this can mess up
certain tools like tar/find, and NFS).
In Unionfs we implemented yet another alternative (called "imap" or Inode
Map). We generate unique inums, but we store them persistently on the lower
f/s, in a special mapping file. That way we can map our own stacked inums
to the lower ones. So this allows you to cross into any number of sb's, and
it works with NFS (client/server) and with tools like tar and find. Problem
is, performance now suffers each time you have to consult the i-mapping file
to translate b/t upper and lower inums.
Erez.
^ permalink raw reply
* [Qemu-devel] Unified device model
From: Stanislav Shwartsman @ 2006-04-08 19:57 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]
Hello All,
It is not a secret that all open source emulators (QEMU, Bochs, Xen) use the
same emulated devices and mostly copy-paste their emulation one from
another.
I don't know who originally wrote the device models but now Bochs and QEMU
maintain two similar implementations of the same devices.
If one of the teams fixes the implementation or add functionality, another
team mostly copy-paste the changes to their model.
Xen project forked from QEMU and want to stay in touch with Bochs and QEMU
device models and contribute the changes to make the model better.
I am wondering about making unified device models architecture for open
source simulators.
The device models will be used in QEMU, Bochs, Xen and other open source
simulators which would use the device models.
I know about two professional teams working in simulation which would like
to use these device models in their simulator and
could enrich the device library with new devices device interfaces, for
example with AGP and 3D graphics.
Bochs is already in middle of definition of new true pluginable devices
architecture.
In near future Bochs devices will fully separatable from Bochs binary and
when could be developed separately from Bochs.
I call to QEMU developers join to this project and come with their
requirements to plugin architecture.
I don't know if QEMU supports device plugins now but I would like to see
QEMU a part of this idea,
I would like to get single device shared library which could be loaded to
Bochs and QEMU and work perfectly for both.
This will eliminate the need to maintain two separate implementations of the
same devices,
these implementations very fast will converge to single one, C or C++ based,
Bochs or QEMU based, doesn't matter.
I am listening for your opinions !
Thanks,
Stanislav
[-- Attachment #2: Type: text/html, Size: 5766 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] sbp2: remove manipulation of inquiry response
From: Stefan Richter @ 2006-04-08 18:55 UTC (permalink / raw)
To: linux-scsi; +Cc: linux1394-devel
In-Reply-To: <tkrat.d3b4470a9a767dd4@s5r6.in-berlin.de>
I wrote:
> This code became ineffective a few Linux releases ago and is
> apparently not required anyway.
PS: Of my SBP-2 devices, 3 of 3 CD-RWs and 3 of 7 HDDs report a SCSI
level of 0. With and without the patch.
--
Stefan Richter
-=====-=-==- -=-- -=---
http://arcgraph.de/sr/
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Johannes Schindelin @ 2006-04-08 18:53 UTC (permalink / raw)
To: Mark Williamson; +Cc: qemu-devel
In-Reply-To: <200604081938.02130.mark.williamson@cl.cam.ac.uk>
Hi,
On Sat, 8 Apr 2006, Mark Williamson wrote:
> The Xen copy of pckbd.c includes a patch to emulate a Summagraphics
> tablet, in order to fix this problem. This is probably reusable for
> QEmu itself.
I even know who wrote it... Donald Dugger. He forwarded it to me also, and
I even think it is part of the RFB patch (too lazy to check right now).
There are two problems:
- configuration is a bitch. For example, X and gpm do not play nice
together. And there is no automatic detection for Summagraphics in kudzu
(which is the automatic hardware detection of Knoppix).
- the patch modifies the PS/2 mouse of QEmu. However, there is no such
thing as a PS/2 Summagraphics. Consequently, all win98 drivers I found did
not detect a Summagraphics device.
Ciao,
Dscho
^ permalink raw reply
* [RFC PATCH] sbp2: remove manipulation of inquiry response
From: Stefan Richter @ 2006-04-08 18:45 UTC (permalink / raw)
To: linux-scsi; +Cc: linux1394-devel
This code became ineffective a few Linux releases ago and is
apparently not required anyway.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Index: linux-2.6.17-rc1/drivers/ieee1394/sbp2.c
===================================================================
--- linux-2.6.17-rc1.orig/drivers/ieee1394/sbp2.c 2006-04-08 09:43:33.000000000 +0200
+++ linux-2.6.17-rc1/drivers/ieee1394/sbp2.c 2006-04-08 20:40:00.000000000 +0200
@@ -2079,33 +2079,6 @@ static unsigned int sbp2_status_to_sense
}
/*
- * This function is called after a command is completed, in order to do any necessary SBP-2
- * response data translations for the SCSI stack
- */
-static void sbp2_check_sbp2_response(struct scsi_id_instance_data *scsi_id,
- struct scsi_cmnd *SCpnt)
-{
- u8 *scsi_buf = SCpnt->request_buffer;
-
- SBP2_DEBUG_ENTER();
-
- if (SCpnt->cmnd[0] == INQUIRY && (SCpnt->cmnd[1] & 3) == 0) {
- /*
- * Make sure data length is ok. Minimum length is 36 bytes
- */
- if (scsi_buf[4] == 0) {
- scsi_buf[4] = 36 - 5;
- }
-
- /*
- * Fix ansi revision and response data format
- */
- scsi_buf[2] |= 2;
- scsi_buf[3] = (scsi_buf[3] & 0xf0) | 2;
- }
-}
-
-/*
* This function deals with status writes from the SBP-2 device
*/
static int sbp2_handle_status_write(struct hpsb_host *host, int nodeid, int destid,
@@ -2444,13 +2417,6 @@ static void sbp2scsi_complete_command(st
}
/*
- * Take care of any sbp2 response data mucking here (RBC stuff, etc.)
- */
- if (SCpnt->result == DID_OK << 16) {
- sbp2_check_sbp2_response(scsi_id, SCpnt);
- }
-
- /*
* If a bus reset is in progress and there was an error, complete
* the command as busy so that it will get retried.
*/
Index: linux-2.6.17-rc1/drivers/ieee1394/sbp2.h
===================================================================
--- linux-2.6.17-rc1.orig/drivers/ieee1394/sbp2.h 2006-04-08 09:43:32.000000000 +0200
+++ linux-2.6.17-rc1/drivers/ieee1394/sbp2.h 2006-04-08 20:40:00.000000000 +0200
@@ -394,9 +394,8 @@ static int sbp2_link_orb_command(struct
static int sbp2_send_command(struct scsi_id_instance_data *scsi_id,
struct scsi_cmnd *SCpnt,
void (*done)(struct scsi_cmnd *));
-static unsigned int sbp2_status_to_sense_data(unchar *sbp2_status, unchar *sense_data);
-static void sbp2_check_sbp2_response(struct scsi_id_instance_data *scsi_id,
- struct scsi_cmnd *SCpnt);
+static unsigned int sbp2_status_to_sense_data(unchar *sbp2_status,
+ unchar *sense_data);
static void sbp2_parse_unit_directory(struct scsi_id_instance_data *scsi_id,
struct unit_directory *ud);
static int sbp2_set_busy_timeout(struct scsi_id_instance_data *scsi_id);
^ permalink raw reply
* Re: [Bugme-new] [Bug 6357] New: Megaraid driver is more recent for my hardware
From: Andrew Morton @ 2006-04-08 18:41 UTC (permalink / raw)
To: Neela.Kolli; +Cc: qdiverses, bugme-daemon@kernel-bugs.osdl.org, linux-scsi
In-Reply-To: <200604081650.k38Goegv012572@fire-2.osdl.org>
bugme-daemon@bugzilla.kernel.org wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6357
>
> Summary: Megaraid driver is more recent for my hardware
> Kernel Version: 2.4.8 -> 2.6.16.1
> Status: NEW
> Severity: blocking
> Owner: scsi_drivers-other@kernel-bugs.osdl.org
> Submitter: qdiverses@ifrance.com
>
>
> Most recent kernel where this bug did not occur:
> Distribution: Debian Sarge
> Hardware Environment: Hp Netserver LH3 with Netraid (driver Megaraid)
> Software Environment: Without, I try to update
> Problem Description:
> Hello from France,
> I install with my CD, Debian with a 2.4.8 Kernel. My SCSI card was ok with the
> megaraid driver. I try to update the kernel with the 2.6.16.1 version. But
> after the boot hang on my Scsi card. I read this, a new driver for the megaraid
> is present on the 2.6 kernel. And it doesn't work with my "old" card.
> How can I copy, compile, .... the megaraid driver of 2.4 kernel in 2.6 kenel.
> I start in the world linux and kernel. Can you explain with more sentence
>
^ permalink raw reply
* [lm-sensors] nForce 430 SMBus
From: Jean Delvare @ 2006-04-08 18:42 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <74ee72ca0604071607l1c1063b2iad93659df1bfe3fa@mail.gmail.com>
Hi Mark,
> > Hey, good work. lease provide the output of (as root):
> > lspci -s 00:0a.1 -xxx
>
> Here it is:
> lspci -s 00:0a.1 -xxx
> 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a2)
> 00: de 10 64 02 01 00 b0 00 a2 00 05 0c 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 01 06 00 00 01 07 00 00 00 00 00 00 de 10 84 cb
> 30: 00 00 00 00 44 00 00 00 00 00 00 00 05 01 00 00
> 40: de 10 84 cb 01 00 02 c0 00 00 00 00 00 00 00 00
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 01 05 00 00 01 08 00 00 01 09 00 00 00 00 00 00
> 70: 01 00 00 00 00 00 b8 fe 00 00 fe fe 01 20 00 00
OK, that explains it. The driver was looking for the base I/O addresses
at (non-standard registers) 0x50 and 0x54. You have them at (standard
registers) 0x20 and 0x24.
I did some search and it seems that previous nforce4 devices had each
address listed twice (once in the non-standard register and once in the
standard register). Original nforce2 devices had only the non-standard
ones though, which explains why the driver was using them.
So my guess is that Nvidia tried to move to the standard register,
which isn't a bad thing, and kept the old ones around for some times
for compatibility purposes (not a bad idea either.) And your device is
the first one without that compatibility measure, so the driver broke.
I modified the driver so that it'll check the standard register first,
and fallback to the non-standard one when needed (older devices.) Patch
follows:
Add support for the new nForce4 MCP51 (also known as nForce 410 or
430) to the i2c-nforce2 driver. Some code changes were required because
the base I/O address registers have changed in this version. Standard
BARs are now being used, while the original nForce2 chips used
non-standard ones.
Signed-off-by: Jean Delvare <khali at linux-fr.org>
---
drivers/i2c/busses/i2c-nforce2.c | 18 +++++++++++++-----
include/linux/pci_ids.h | 1 +
2 files changed, 14 insertions(+), 5 deletions(-)
--- linux-2.6.17-rc1.orig/drivers/i2c/busses/i2c-nforce2.c 2006-03-27 18:18:57.000000000 +0200
+++ linux-2.6.17-rc1/drivers/i2c/busses/i2c-nforce2.c 2006-04-08 20:29:13.000000000 +0200
@@ -31,6 +31,7 @@
nForce3 250Gb MCP 00E4
nForce4 MCP 0052
nForce4 MCP-04 0034
+ nForce4 MCP51 0264
This driver supports the 2 SMBuses that are included in the MCP of the
nForce2/3/4 chipsets.
@@ -259,6 +260,7 @@
{ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE3S_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE4_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP04_SMBUS) },
+ { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_SMBUS) },
{ 0 }
};
@@ -267,17 +269,20 @@
static int __devinit nforce2_probe_smb (struct pci_dev *dev, int reg,
- struct nforce2_smbus *smbus, char *name)
+ int alt_reg, struct nforce2_smbus *smbus, char *name)
{
u16 iobase;
int error;
- if (pci_read_config_word(dev, reg, &iobase) != PCIBIOS_SUCCESSFUL) {
+ /* Older incarnations of the device used non-standard BARs */
+ if (pci_read_config_word(dev, reg, &iobase) != PCIBIOS_SUCCESSFUL
+ || (!iobase && pci_read_config_word(dev, alt_reg, &iobase)
+ != PCIBIOS_SUCCESSFUL)) {
dev_err(&smbus->adapter.dev, "Error reading PCI config for %s\n", name);
return -1;
}
smbus->dev = dev;
- smbus->base = iobase & 0xfffc;
+ smbus->base = iobase & PCI_BASE_ADDRESS_IO_MASK;
smbus->size = 8;
if (!request_region(smbus->base, smbus->size, nforce2_driver.name)) {
@@ -313,12 +318,15 @@
pci_set_drvdata(dev, smbuses);
/* SMBus adapter 1 */
- res1 = nforce2_probe_smb (dev, NFORCE_PCI_SMB1, &smbuses[0], "SMB1");
+ res1 = nforce2_probe_smb(dev, PCI_BASE_ADDRESS_4, NFORCE_PCI_SMB1,
+ &smbuses[0], "SMB1");
if (res1 < 0) {
dev_err(&dev->dev, "Error probing SMB1.\n");
smbuses[0].base = 0; /* to have a check value */
}
- res2 = nforce2_probe_smb (dev, NFORCE_PCI_SMB2, &smbuses[1], "SMB2");
+ /* SMBus adapter 2 */
+ res2 = nforce2_probe_smb(dev, PCI_BASE_ADDRESS_5, NFORCE_PCI_SMB2,
+ &smbuses[1], "SMB2");
if (res2 < 0) {
dev_err(&dev->dev, "Error probing SMB2.\n");
smbuses[1].base = 0; /* to have a check value */
--- linux-2.6.17-rc1.orig/include/linux/pci_ids.h 2006-04-03 20:50:44.000000000 +0200
+++ linux-2.6.17-rc1/include/linux/pci_ids.h 2006-04-08 18:46:22.000000000 +0200
@@ -1124,6 +1124,7 @@
#define PCI_DEVICE_ID_NVIDIA_QUADRO4_900XGL 0x0258
#define PCI_DEVICE_ID_NVIDIA_QUADRO4_750XGL 0x0259
#define PCI_DEVICE_ID_NVIDIA_QUADRO4_700XGL 0x025B
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_SMBUS 0x0264
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_IDE 0x0265
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_SATA 0x0266
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_SATA2 0x0267
Mark (McKnight), can you please try it too? It should work for you too.
Other users of i2c-nforce2 are invited to test that patch too, just to
make sure I did not accidentally break the older chips.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Mark Williamson @ 2006-04-08 18:38 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082003380.7783@wbgn013.biozentrum.uni-wuerzburg.de>
> On Sat, 8 Apr 2006, Samuel Hunt wrote:
> > It occurs to me that this program would make an excellent basis for a VNC
> > terminal server.
>
> Yeah, something like that has been done already:
> http://libvncserver.sourceforge.net/qemu/qemu-rfb13.patch.gz
>
> There is a notable update since rfb12 (which is a bit out of date
> _cough_): Nis Jorgensen has sent a patch to support scroll mice.
>
> IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse
> support is rather flakey: You have to disable mouse acceleration of the
> guest OS.
>
> I had that cunning plan to write a virtual Wacom tablet, but I just don't
> find the time.
The Xen copy of pckbd.c includes a patch to emulate a Summagraphics tablet, in
order to fix this problem. This is probably reusable for QEmu itself.
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.