* RE: [Qemu-devel] Unified device model
From: Stanislav Shwartsman @ 2006-04-09 6:26 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20060408191219.GB16963@jbrown.mylinuxbox.org>
Hi again,
>>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 am talking about the device models only. Inside CPU emulation QEMU, Bochs
and Xen are completely different, but they use the same devices for full
system emulation and they most likely want to move forward together. The
devices system of QEMU and Bochs become outdate, it is required to add ACPI
compliance and emulate new modern ACPI compatible devices, currently
emulated i440FX already not so represent the real life and most of the
modern OSes already have no support for it.
>> 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.
So may we should ;)
At least I see the code changes from Bochs migrating to QEMU and vise versa
when I am looking into the code.
>>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 know that it is completely independent project. But their device models
could be called separate project Xen-HWEMU and it is fork from QEMU.
>>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.
Why not ?
You always could consider to add simple modules C++ to QEMU or build C++
device -> C device interface bridge ...
I don't know all the possibilities, but I am sure there are more.
>>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.
Currently we are thinking about making user-plugin PCI devices and when
later user-plugin for any device. The C++ hierarchy for now might be:
bx_devmodel_c - bx_pcidev_c - bx_user_pcidev_c
The plans are to take one of the Bochs PCI devices and convert it into
user-level plugin which should not be compiled with Bochs and even not known
at compile time, but loaded at runtime if selected in runtime config file.
When any other device models could be added, even with closed-sources and
commercial licenses.
>The primary reason given for not making a plugin API for qemu hardware
>emulationis 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.
Ok, I didn't knew that QEMU is so unstable. But at least there are several
trivial requirements from plugin architecture which you could mention here
and I am still not thought about it. I know, basically I am writing the
definition in my idle time and Volker supporting me. But it is not enough
...
Thanks,
Stanislav
^ permalink raw reply
* [lm-sensors] hwmon/pc87360 as a platform driver
From: Juerg Haefliger @ 2006-04-09 5:24 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4436BE3B.7090306@gmail.com>
> The SHOW_SET_*_* constants are just a bit off-putting at first read,
> but I know what you mean, and I dont have a better idea.
> maybe SHOW_SETTNG_*_* ?
> or SHOW_CURR_*_*, thats confuse-able with the current reading
Well SHOW_SET_xxx_yyy is supposed to hint that the constant is used in
both the show_xxx and set_xxx callbacks. It's the best I could come up
with although I have to admit I didn't spend too much time thinking
about this....
>
> you can improve your printks :
>
> s/(printk\(KERN_DEBUG)/dev_dbg\(&pdev->dev/;
> s/(printk\(KERN_ERR)/dev_err\(&pdev->dev/
> s/(printk\(KERN_INFO)/dev_info\(&pdev->dev/
>
> at least where pdev has already been initd
Hmm... I thought I used printks only in places where pdev is not initialized.
>
> Ill try to read thru the enire patch this weekend sometime.
I certainly appreciate the review :-)
...juerg
^ permalink raw reply
* Re: Accessing physical memory
From: dwh @ 2006-04-09 4:20 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200604082352.55490.antonio.dibacco@aruba.it>
Quoting Antonio Di Bacco <antonio.dibacco@aruba.it>:
> How can I access the physical memory? Can I MMAP for example /dev/mem? Is
> there a simpler way?
>
Hi Antonio,
What would you like to do? If you just want some arbitrary
page of memory, then look at the 'nopage' example in Rubini,
or ask me and I'll send you some code.
If you want a specific memory location, then you'll need
to claim and ioremap the memory, and again, I can give you
some code.
So, explain a little more and I can help.
Dave
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
From: Al Boldi @ 2006-04-09 5:04 UTC (permalink / raw)
To: Peter Williams; +Cc: linux-kernel
In-Reply-To: <44387855.30004@bigpond.net.au>
Peter Williams wrote:
> Al Boldi wrote:
> > This is especially visible in spa_no_frills, and spa_ws recovers from
> > this lockup somewhat and starts exhibiting this problem as a choking
> > behavior.
> >
> > Running '# top d.1 (then shift T)' on another vt shows this choking
> > behavior as the proc gets boosted.
>
> But anyway, based on the evidence, I think the problem is caused by the
> fact that the eatm tasks are running to completion in less than one time
> slice without sleeping and this means that they never have their
> priorities reassessed.
Yes.
> The reason that spa_ebs doesn't demonstrate the
> problem is that it uses a smaller time slice for the first time slice
> that a task gets. The reason that it does this is that it gives newly
> forked processes a fairly high priority and if they're left to run for a
> full 120 msecs at that high priority they can hose the system. Having a
> shorter first time slice gives the scheduler a chance to reassess the
> task's priority before it does much damage.
But how does this explain spa_no_frills setting promotion to max not having
this problem?
> The reason that the other schedulers don't have this strategy is that I
> didn't think that it was necessary. Obviously I was wrong and should
> extend it to the other schedulers. It's doubtful whether this will help
> a great deal with spa_no_frills as it is pure round robin and doesn't
> reassess priorities except when nice changes of the task changes
> policies.
Would it hurt to add it to spa_no_frills and let the children inherit it?
> This is one good reason not to use spa_no_frills on
> production systems.
spa_ebs is great, but rather bursty. Even setting max_ia_bonus=0 doesn't fix
that. Is there a way to smooth it like spa_no_frills?
> Perhaps you should consider creating a child
> scheduler on top of it that meets your needs?
Perhaps.
> Anyway, an alternative (and safer) way to reduce the effects of this
> problem (while your waiting for me to do the above change) is to reduce
> the size of the time slice. The only bad effects of doing this is that
> you'll do slightly worse (less than 1%) on kernbench.
Actually, setting timeslice to 5,50,100 gives me better performance on
kernbench. After closer inspection, I found 120ms a rather awkward
timeslice whereas 5,50, and 100 exhibited a smoother and faster response,
which may be machine dependent, thus the need for an autotuner.
Thanks!
--
Al
^ permalink raw reply
* Re: Overhead of Using a Stackable File System(Wrapfs)
From: UZAIR LAKHANI @ 2006-04-09 4:56 UTC (permalink / raw)
To: Avishay Traeger; +Cc: linux-fsdevel
In-Reply-To: <1144501472.13374.8.camel@ool-44c32f98.dyn.optonline.net>
--- Avishay Traeger <atraeger@cs.sunysb.edu> wrote:
> On Fri, 2006-04-07 at 23:48 -0700, UZAIR LAKHANI
> wrote:
> > Thanks for replying but consider this scenario.
> >
> > What Wrapfs code do is this
> >
> > user_request ---> vfs_request ---> wrapfs_request
> --->
> > actual_fs_request ---> storage
> >
> > Now consider this scenario in a network
> environment
> >
> > (client machine)
> > user_request ---> vfs_request ---> wrapfs_request
> --->
> >
> > Network ---> (server machine)actual_fs_request
> --->
> > storage
> >
> > The network here gets client requests and send
> them to
> > server and vice versa.
>
> The main benefit of stackable file systems is that
> you do not need to
> duplicate the functionality found in lower-level
> file systems. In your
> scenario, you do not use the lower-level file system
> at all, so you will
> need to implement all the functionality of a
> lower-level file system,
> plus deal with all the stackable file system code
> (which you will use
> but won't need). Using wrapfs in this case will
> give you no benefit,
> and will just make your life more difficult, and
> your code slower and
> more difficult to read. I recommend you just start
> from scratch.
>
Thanks again for replying. I am getting your point
that we don't have any lower filesystem on the client
side but can we not assume that we have a lower file
sytem on client side but that actually resides across
the network on server side. All then we have to do is
to pass the requsts for the lower file system on
client side to the lower file system on server side
using some communication mechanism.
Waiting for comments.
Thanks,
Uzair
> Avishay Traeger
> http://www.fsl.cs.sunysb.edu/~avishay/
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Anthony Liguori @ 2006-04-09 4:36 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <443825D8.3080602@win4lin.com>
I was looking through the Xorg evdev driver and it doesn't appear to
support absolute coordinate reporting. evdev is how the USB mouse would
show up to userspace. A little googling confirmed it for me:
http://lists.freedesktop.org/archives/xorg/2005-September/010140.html
USB wacom still seems the most promising to me but I fear getting it to
work under Windows will be a pain.
Regards,
Anthony Liguori
Leonardo E. Reiter wrote:
> This is by no means a complete patch (do not apply it as it will break
> usb-hid.c), but it adjusts the report descriptor in usb-hid.c to
> provide position in 16-bits, and in absolute coordinates:
>
> Index: usb-hid.c
> ===================================================================
> RCS file: /cvsroot/qemu/qemu/hw/usb-hid.c,v
> retrieving revision 1.1
> diff -a -u -r1.1 usb-hid.c
> --- usb-hid.c 5 Nov 2005 16:57:08 -0000 1.1
> +++ usb-hid.c 8 Apr 2006 20:56:02 -0000
> @@ -117,7 +117,7 @@
> 0x15, 0x00, 0x25, 0x01, 0x95, 0x03, 0x75, 0x01,
> 0x81, 0x02, 0x95, 0x01, 0x75, 0x05, 0x81, 0x01,
> 0x05, 0x01, 0x09, 0x30, 0x09, 0x31, 0x15, 0x81,
> - 0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06,
> + 0x25, 0x7F, 0x75, 0x16, 0x95, 0x02, 0x81, 0x02,
> 0xC0, 0xC0,
> };
>
> According to:
> http://72.14.203.104/search?q=cache:wVYUTwc33f8J:www.usb.org/developers/devclass_docs/HID1_11.pdf+usb+hid+specification+absolute+relative&hl=en&gl=us&ct=clnk&cd=1
>
>
> I'm still trying to figure out how the logical min/max apply if we are
> to report absolute (unsigned) positions in 16-bits. Obviously 8-bits
> is not enough for absolute coordinates. You could theoretically use
> only 12-bits per coordinate but that would make life difficult I
> think, and probably unnecessarily frugal in a software emulation.
>
> It's not clear to me [yet] how the scroll wheel comes into play, and
> whether or not it (the dz coordinate) can be kept relative for ease of
> implementation. Also the code would need to be changed to report
> coordinates in 16-bits rather than 8, and of course made to report
> absolute coordinates (like from sdl.c, etc.) Still it looks fairly
> easy to implement - the USB spec is pretty simple.
>
> So to reiterate, my patch does virtually nothing - in fact it will
> break usb-hid.c so please don't use it. I was just illustrating how
> to get it to report the device as providing 16-bit absolute
> coordinates instead of 8-bit relative ones. If anyone wants to chime
> in with more info, I'd be glad to make this a discussion. *If* using
> the USB HID device only, not any real USB devices, can be done without
> slowing down QEMU, then I think this is a great way to get a tablet
> emulated without having to deal with drivers on either side. Plus, in
> the long run, it probably means other neat stuff like being able to
> get away from ISA bus emulation, and also it's portable to other
> targets (for example, OS-X on PPC would talk to the USB HID device the
> same way theoretically), so it's likely the most portable and cleanest
> option.
>
> Regards,
>
> Leo Reiter
>
> Brad Campbell wrote:
>> Apparently USB HID supports absolute input devices natively. Given we
>> have a HID mouse driver of sorts in qemu I wonder if that is another
>> avenue perhaps ?
>>
>>
>
^ permalink raw reply
* Redirecting packets based on source+destination ip's
From: clan @ 2006-04-09 4:34 UTC (permalink / raw)
To: netfilter
I have been trying to find a way with iptables to redirect a packet
created on a server to be sent to 1.1.1.1 instead of 2.2.2.2 but only if
the packet is coming from 3.3.3.3.
With the help of linuxquestions.org I have gotten to the point of using
DNAT where the packet redirects, but the determining factor is destination
address. Not source. Since this is a shared server(each user has a
different ip) it would be nice to only redirect certain ip's, but leave
the others alone.
In case I didn't make it understandable what I want to do here is what I
am trying to accomplish, I rent a server for running a battlefield 2
server. This is of course shared, so there are other battlefield
instances running next to mine albeit on different ip's. I want to run a
stats program that requires redirecting bf2web.gamespy.com to
212.77.171.103 so that when my server sends out stats they go to ABR
instead of EA. The usual way of doing this is with a hosts file, but that
effects all ip's on the server, and causes some pretty big problems with
the other servers on the machine.
Here is what the guy at linuxquestions.org gave me to work with
iptables -t nat -A PREROUTING -t nat -p tcp -d 1.1.1.1 --dport 80 -j DNAT
--to 2.2.2.2
To make it work I had to change PREROUTING to OUTPUT. So is there a way
for that to only effect certain source ip's?
Thank you so much, Fourthbean
^ permalink raw reply
* Astounding Mortgages for the USA!
From: Elinor Arellano @ 2006-04-09 5:28 UTC (permalink / raw)
To: linux-scsi
Homeowner
You have been pre-approved for a $455,843 Home Loan at a 3.76 Fixed Rate.
This offer is being extended to you unconditionally and your credit is in no way a factor.
To take Advantage of this Limited Time opportunity
All we ask is that you visit our Website and complete
The 1 minute post Approval Form
http://www5.h0ok.com/was.asp
Best Wishes,
Hannah Mayfield
^ permalink raw reply
* Re: bind mount not working as expected
From: Ian Kent @ 2006-04-09 4:24 UTC (permalink / raw)
To: Anthony M. Martinez; +Cc: autofs, Timo Felbinger
In-Reply-To: <20060406152922.GD10241@nmt.edu>
On Thu, 6 Apr 2006, Anthony M. Martinez wrote:
> As suggested, I am forwarding this question to the autofs mailing list,
> since my problem doesn't seem to be Timo's patch.
>
> On Fri, Mar 24, 2006 at 06:05:31PM +0100, Timo Felbinger wrote:
> > On Thu, Mar 23, 2006 at 09:57:15AM -0700, Pi (aka Anthony Martinez) wrote:
> > > > >
> > > > Is it correct that this is a "program" map which is to telling
> > > > automount to mount /fs/administratium/accounts/p/pi as /u/pi,
> > > > and this information is taken from an ldap entry containing the
> > > > attributes
> > > > uid: pi
> > > > tccRawHomeDir: /fs/administratium/accounts/p/pi
^
Where's the hostname on this !
tccRawHomeDir: :/fs/administratium/accounts/p/pi
^
Sun map escape might be needed?
Ian
^ permalink raw reply
* Re: cross automount issue
From: Ian Kent @ 2006-04-09 4:19 UTC (permalink / raw)
To: Joe Pruett; +Cc: autofs
In-Reply-To: <Pine.LNX.4.64.0604070923300.15746@q7.q7.com>
On Fri, 7 Apr 2006, Joe Pruett wrote:
> after sending it, i started wondering what the lock was there for. i wasn't
> sure if each automount daemon was multi-threaded or not. what mount locking
> are you referring to?
The lock was introduced to prevent corruption of /etc/mtab because the
locking in mount for this purpose didn't work.
There are patches for mount which I believe fix it.
Ian
^ permalink raw reply
* [Ocfs2-devel] using ethernet instead of TCP
From: Wim Coekaerts @ 2006-04-09 4:13 UTC (permalink / raw)
To: ocfs2-devel
In-Reply-To: <AEC6C66638C05B468B556EA548C1A77DCEBF59@trantor>
nope not yet :)
On Sun, Apr 09, 2006 at 01:56:32PM +1000, James Harper wrote:
> Has anyone considered having the option of using Ethernet instead of TCP
> for inter-node communications? Such a feature would be useful for me as
> I'd like to use the same Ethernet segment for inter-node communication
> as I run AoE over (much less chance of a split brain), but I don't
> currently run IP on that segment. Also, running ocfs2 as the root
> filesystem would be easier (I've asked on -users if this is a good idea,
> as discussion of that aspect probably isn't appropriate to -devel) as IP
> wouldn't need to be started before bringing the root filesystem online.
>
> Obviously it's going to limit the cluster to the one lan segment, and
> you get a lot of stuff 'for free' with TCP that would have to be written
> for ocfs2 to use Ethernet (but I don't know how much the inter-node
> stuff actually makes use of it), so it might be too much work for too
> little gain...
>
> Thanks
>
> James
>
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs2-devel
^ permalink raw reply
* [LARTC] Simultaneous iptables calls
From: Daniel Webb @ 2006-04-09 4:12 UTC (permalink / raw)
To: lartc
Run this as one process:
#!/bin/sh
while [ 1 = 1 ]; do
iptables -t mangle -F chain1
iptables -t mangle -X chain1
iptables -t mangle -N chain1 || exit 1
done
Run this as another process:
#!/bin/sh
while [ 1 = 1 ]; do
iptables -t mangle -F chain2
iptables -t mangle -X chain2
iptables -t mangle -N chain2 || exit 1
done
and you get:
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: Unknown error 4294967295
iptables: Unknown error 4294967295
iptables: Chain already exists
iptables: Unknown error 4294967295
iptables: Unknown error 4294967295
iptables: Unknown error 4294967295
iptables v1.3.5: can't initialize iptables table `mangle': Bad file descriptor
Perhaps iptables or your kernel needs to be upgraded.
<... etc>
I'm don't understand the things going on under the surface, so maybe there is
a reason it's impossible to have some kind of locking to prevent this, like
for example, with chmod:
#!/bin/sh
while [ 1 = 1 ]; do
chmod 777 mod_me
done
#!/bin/sh
while [ 1 = 1 ]; do
chmod 666 mod_me
done
(no errors)
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: Linux 2.6.17-rc1: /sbin/iptables does not find kernel netfilter
From: Patrick McHardy @ 2006-04-09 4:09 UTC (permalink / raw)
To: vherva; +Cc: linux-kernel
In-Reply-To: <20060408200915.GN1686@vianova.fi>
Ville Herva wrote:
> I upgraded from 2.6.15-rc7 to 2.6.17-rc1. rc1 seems nice other than that
> iptables stopped working:
>
> failed iptables v1.3.5: can't initialize iptables table filter: iptables
> who? (do you need to insmod?)
> Perhaps iptables or your kernel needs to be upgraded.
>
> iptables is compiled in the kernel, not a module:
> CONFIG_NETFILTER=y
>
> I can even do "modprobe iptable_nat" successfully (iptable_nat is module),
> but iptables refuses to work. iptables is of version iptables-1.3.5-1.2.
>
> The kernel config is copied with make oldconfig from 2.6.15-rc7 (which
> worked), not much else has changed. I just booted back to 2.6.15-rc7 and
> verified it works. Any ideas?
Most likely you didn't enable the new xtables options. Please post your
full config.
^ permalink raw reply
* Total Language Solution
From: Jason @ 2006-04-09 3:58 UTC (permalink / raw)
To: linux-scsi
Dear Sir,
We would like to take this opportunity to introduce our company.
We are a professional translation company£¬one of China¡¯s leading translation & interpretation companies, dedicates herself in providing our clients with highly professional language solutions.
In a global marketplace distinguished by remarkable growth and consolidation, We provides many language solutions that will assist in effective communication and organizational development.
All of our existing clients are continually looking to acquire best language solutions in order to improve business process and break through bottle neck, which enables them to gain competitive advantages and attain commercial objectives.
With over 200 highly qualified translators and interpreters with local and international industrial experience, We generates revenue from a client list including over 60% of world top 1000 companies
By providing translation and interpretation services in different industries, WTC people are passionate to deliver premium products and services that meet all of your personal and company needs.
If you have any requirements, please feel free to contact us.
For more information, please reply to this.
Best regards
Jason
Account Exective: Jason
M P: 13482251975
Q Q: 87386590
email:haibinjia@yahoo.com.cn
JASON
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Ocfs2-devel] using ethernet instead of TCP
From: James Harper @ 2006-04-09 3:56 UTC (permalink / raw)
To: ocfs2-devel
Has anyone considered having the option of using Ethernet instead of TCP
for inter-node communications? Such a feature would be useful for me as
I'd like to use the same Ethernet segment for inter-node communication
as I run AoE over (much less chance of a split brain), but I don't
currently run IP on that segment. Also, running ocfs2 as the root
filesystem would be easier (I've asked on -users if this is a good idea,
as discussion of that aspect probably isn't appropriate to -devel) as IP
wouldn't need to be started before bringing the root filesystem online.
Obviously it's going to limit the cluster to the one lan segment, and
you get a lot of stuff 'for free' with TCP that would have to be written
for ocfs2 to use Ethernet (but I don't know how much the inter-node
stuff actually makes use of it), so it might be too much work for too
little gain...
Thanks
James
^ permalink raw reply
* Burn calories
From: Britney Yazzie @ 2006-04-09 3:51 UTC (permalink / raw)
To: sparclinux
Summer is coming, did you look in the mirror lately?
If you`re still overweight you MUST visit us:
http://051.inexpensiveformula.com
WE WILL HELP YOU!
alto you raj me, burp vest neuromuscular expansible . adriatic you artichoke me, reedy handicraftsmen .
shade you plaintiff me, metcalf buckwheat . perform you chime me, midwives resent dylan .
http://051.inexpensiveformula.com/rm/
^ permalink raw reply
* [PATCH] diffcore-rename: fix merging back a broken pair.
From: Junio C Hamano @ 2006-04-09 3:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vwtdzcvhb.fsf@assigned-by-dhcp.cox.net>
When a broken pair is matched up by rename detector to be merged
back, we do not want to say it is "dissimilar" with the
similarity index. The output should just say they were changed,
taking the break score left by the earlier diffcore-break run if
any.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diffcore-rename.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
c17de73d793ff20fce6bcc8427e5f10ab8a2a7c5
diff --git a/diffcore-rename.c b/diffcore-rename.c
index e992698..d57e865 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -54,12 +54,14 @@ static struct diff_rename_dst *locate_re
/* Table of rename/copy src files */
static struct diff_rename_src {
struct diff_filespec *one;
+ unsigned short score; /* to remember the break score */
unsigned src_path_left : 1;
} *rename_src;
static int rename_src_nr, rename_src_alloc;
static struct diff_rename_src *register_rename_src(struct diff_filespec *one,
- int src_path_left)
+ int src_path_left,
+ unsigned short score)
{
int first, last;
@@ -89,6 +91,7 @@ static struct diff_rename_src *register_
memmove(rename_src + first + 1, rename_src + first,
(rename_src_nr - first - 1) * sizeof(*rename_src));
rename_src[first].one = one;
+ rename_src[first].score = score;
rename_src[first].src_path_left = src_path_left;
return &(rename_src[first]);
}
@@ -198,7 +201,10 @@ static void record_rename_pair(int dst_i
fill_filespec(two, dst->sha1, dst->mode);
dp = diff_queue(NULL, one, two);
- dp->score = score;
+ if (!strcmp(src->path, dst->path))
+ dp->score = rename_src[src_index].score;
+ else
+ dp->score = score;
dp->source_stays = rename_src[src_index].src_path_left;
rename_dst[dst_index].pair = dp;
}
@@ -256,10 +262,10 @@ void diffcore_rename(struct diff_options
* that means the source actually stays.
*/
int stays = (p->broken_pair && !p->score);
- register_rename_src(p->one, stays);
+ register_rename_src(p->one, stays, p->score);
}
else if (detect_rename == DIFF_DETECT_COPY)
- register_rename_src(p->one, 1);
+ register_rename_src(p->one, 1, p->score);
}
if (rename_dst_nr == 0 || rename_src_nr == 0 ||
(0 < rename_limit && rename_limit < rename_dst_nr))
--
1.2.6.gad0b
^ permalink raw reply related
* Re: Page Migration: Make do_swap_page redo the fault
From: Hugh Dickins @ 2006-04-09 3:11 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linux-mm
In-Reply-To: <Pine.LNX.4.64.0604081430280.17911@schroedinger.engr.sgi.com>
On Sat, 8 Apr 2006, Christoph Lameter wrote:
> On Sat, 8 Apr 2006, Hugh Dickins wrote:
> >
> > 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.
>
> Those two checks were added for migration together with the one we
> are removing now. Sounds like you think they additionally fix some other
> race conditions?
Of course, you're right - sorry. Whatever was I looking at,
to get it so confidently wrong? Dunno: scary.
But I do have to worry then. I'd missed the addition of those checks:
if they really are necessary, then the rules have changed in two
tricky areas I now need to re-understand. It'll take me a while.
Thanks for setting me straight.
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
* RE: kernel vs user power management
From: Brown, Len @ 2006-04-09 3:06 UTC (permalink / raw)
To: Holger Macht; +Cc: thoenig, linux-acpi, linux-laptop, Andi Kleen
>On Sat 08. Apr - 02:42:12, Brown, Len wrote:
>> Timo, Holger,
>> Andi pointed me to your FOSDEM Linux Power Management presentation:
>>
>> http://en.opensuse.org/FOSDEM2006
>>
>> http://files.opensuse.org/opensuse/en/b/b5/One_step_opendesign.pdf
>>
>> And I'm glad to see you working on Linux Power Management.
>>
>> But I'm a little concerned that user-space and the kernel are
>> a little out of sync on a few things.
>>
>> I'm happy to see that the userspace p-state governor
>> is no longer enabled by default on SuSE systems.
>> While it was passable on servers with steady-state
>> workloads, it was very bad for laptops where the
>> machine spends a lot of time idle, but has short
>> bursts of processing need which userspace could
>> not detect. These laptops would spend virtually
>> all their time in Pn when using the userspace governor.
>
>To be honest, this observation suprises me a little bit. We did some
>measurements with userspace agains ondemand governor some time
>ago and did not notice any big differences in the results between them.
>Well, these tests are about 1 1/2 years ago, though, and there went some
>changes into the kernel until now ;-)
Yes, measurements show that ondemand as improved
considerably since its initial implementation.
It continues to improve today, though there is now smaller room for improvement.
Also, the other important thing to meausre here is *response time* --
not throughput. This will expose the benefits of switching quickly
via ondemand vs. slowly via userspace.
This is particularly important on interarctive workloads.
No, you'll not notice much, if any, difference for course grain things
like doing a kernel build or running a steady-state server workload.
>Nevertheless, we adjust the sampling rate in any case and
>currently set it to 333 milliseconds (that's configurable).
>We noticed if we use the
>default ondemand setting, the ondemand governor increases the frequency
>too often although there is not much to do which is also not
>helpful.
I have not observed the ondemand governor today switching up
more often than is helpful.
I speak for intel hardware, of course.
It might be that other hardware, which can not switch up and down
very quickly, not not benefit from ondemand and may be better
suited to userspace.
>But 333 milliseconds is maybe a bit too high, it's taken because
>of historical reasons.
>This value _was_ the default interval of our main event loop.
>I think I will lower it a bit.
Go ahead and tune userspace to work optimally on systems that can't run ondemand.
Systems that are able to run ondemand should not be running userspace
at all.
>Furthermore, we had some problems on multiprocessor systems in the past
>(about 1/2 year ago) with the ondemand governor. After some time the
>system was running (even some hours or even days) the machine locked up
>hard. Thus, we set the userspace governor by default on those systems
>where we never experienced such problems. At the moment I did
>only get one similar report where the root cause is not clear.
It is important that this failure be root caused and this
doubt be put behind us. Got a bug URL?
>So I stick to the
>ondemand governor in any case in newer releases. And such lockups are
>really hard to reproduce and to debug.
>
>Another argument was that speedstep_ich was not yet ready for ondemand
>which it is now IIRC.
speedstep-centrino and acpi-cpufreq support real p-states and can
can support ondemand. (indeed, these two drivers need to be merged into a single driver)
While older systems will use speedstep-ich, I don't expect to see much
use for it on modern systems. p4clockmod is just t-states,
and one could argue that it should not exist at all.
I don't know if the amd-specific drivers would work or not.
Last I heard their latency was too high, but maybe they've
fixed that.
There is a cpufreq architecture issue here here, of course.
the drivers make all the different states look the same
to the governors. But P-states and T-states are not the same,
they are very different.
>> The next step is to delete the userspace governor
>> as a valid governor selection entirely. If somebody
>> really wants manual control, they can still set the
>> limits within which "ondemand" will stay.
>
>In current code, I always try to use the ondemand governor at
>first and if that fails we automatically switch to the userspace
>implementation at runtime.
>
>This way has the advantage that we always get a working cpu
>frequency scaling support.. But it also has one big disadvantage, we do
>not get reports about not working ondemand governor so maybe
>we simply did fot notice the improvements in this area. For our stable
>releases, I will keep the current inplementation. For the unstable one,
>I will disable the
>autoswitching code and if it still works good then for a few
>month, I will remove the userspace implementation completely.
>It should not hurt to let
>the code in for some time and remove the visible configuration option,
>just to have fallback under strange circumstances. Would this
>be ok with you?
I think you'll need to keep the userspace backup scheme for systems
which have switching latency too high to load and run ondemand.
However, systems which can run ondemand, should never run userspace,
and providing userspace as an option on such systems is probably
not the right knob to present to administrators on those boxes.
>> I'm happy to see that clock throttling is not enabled by
>> default in recent SuSE release, at least on my laptop
>> which supports P-states.
>>
>> I'd like to see no option to enable clock-throttling on
>> systems that support real p-states.
>
>Yes, this is reasonable, indeen. Will do that. With p-states in this
>context, you mean cpufreq here?
throttling is always T-states.
cpufreq is usually p-states, but in the case of p4clockmod,
it is T-states also. As I mentioned above, cpufreq is doing
you a dis-service by hiding the difference from you
and really need to be enhanced to know (and export)
the difference.
>> It is useful only for workloads which have an infinite
>> amount of non-idle computing which you don't care how
>> slow it computes. For the vast majority of workloads
>> it just slows down the machine and delays the processor
>> from getting into idle where it can save a non-linear
>> amount of power. Further, there exist today systems which
>> will consume MORE power in deep C-states when throttled
>> vs. when not throttled.
>>
>> The other major topic is the user/kernel interface
>> for power management policy. there needs to be in-kernel
>> state for this, else the device drivers will have no low-latency
>> way to get the answer to the simple policy question of how
>they should
>> optimize for performance vs power at any given instant when they
>> recognize their device is idle.. this state should be controlled
>> by user space, but I think it is most practical for it to
>> be kernel resident.
>
>I'm not sure if I completely understand what you mean here. Do you mean
>the so called "runtime device power management"?
yes.
>If so, I fully agree with you. But I do not set a specific
>policy in the powersave code explicitely for that feature.
>If the policy information
>will go into the kernel, I will use and set this one, of course.
okay, great.
Yes, the kernel folks have known for years that this has to be done.
Hopefully progress will be made soon...
thanks,
-Len
^ permalink raw reply
* Re: [linux-lvm] Recovering data from a damaged LVM partition?
From: Shawn @ 2006-04-09 2:59 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <200604061545.09082.sgrover@open2space.com>
I managed to work out a method to recover the lost data. I've documented this
on my blog (http://grover.open2space.com/node/17), for anyone who may be
facing a similar problem.
Of course, I'm sure those more experienced with LVM may have suggestions, and
I'd be happy to hear them. The solution basically meant learning more about
LVM in general.
Shawn
On Thursday 06 April 2006 15:45, Shawn wrote:
> First post to this list, so please forgive me if I'm not on topic, or
> repeating a common issue.
>
> I have been asked to try to get data from a drive with a damaged partition.
> In the past I've done this with ddrescue, and then mounted the resulting
> image file. That's not working in this case because the partition in
> question was part of an LVM volume.
>
> My experience with LVM is not that great, as I've never seen a need for it
> on my systems. But, I've installed the LVM tools, and modified my kernel
> for LVM support, and can at least see the volume on the damaged drive now.
> But I want to focus on the image file, not the drive.
>
> So, the question is how to mount an image file of an LVM partition?
> Anytime I try the mount command, it's complaining about the file system
> type. I've tried the different options for the -t argument, (and am using
> the -o loop as well).
>
> I'm hesitant to run any of the LVM commands to create a volume set, or
> intialize a partition, for fear of loosing the data. (though I could run
> ddrescue again I suppose, as long as I don't touch the source drive).
>
> Does anyone have any experience here they'd care to share? Thanks.
>
> BTW, the disk in question is from a default install of Fedora Core 4, and
> the system only had a single drive. So LVM probably wasn't needed in this
> case, but the person that installed the system is not comfortable with the
> file system details.
>
> Shawn
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Anthony Liguori @ 2006-04-09 2:59 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <44381019.9070507@win4lin.com>
Leonardo E. Reiter wrote:
> 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.
The driver isn't built into Windows. It's pretty easy to install though
and the way my patch works, the PS/2 mouse is used until it detects the
tablet has been enabled.
The Windows driver uses quite a bit more of the features of the tablet
than the X driver so there's a bit more work to do but nothing
extraordinary.
Regards,
Anthony Liguori
>
> 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.
>
^ permalink raw reply
* Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
From: Peter Williams @ 2006-04-09 2:58 UTC (permalink / raw)
To: Al Boldi; +Cc: linux-kernel
In-Reply-To: <200604082331.56715.a1426z@gawab.com>
Al Boldi wrote:
> Peter Williams wrote:
>> Al Boldi wrote:
>>> Can you try the attached mem-eater passing it the number of kb to be
>>> eaten.
>>>
>>> i.e. '# while :; do ./eatm 9999 ; done'
>>>
>>> This will print the number of bytes eaten and the timing in ms.
>>>
>>> Adjust the number of kb to be eaten such that the timing will be less
>>> than timeslice (120ms by default for spa). Switch to another vt and
>>> start pressing enter. A console lockup should follow within seconds for
>>> all spas except ebs.
>> This doesn't seem to present a problem (other than the eatme loop being
>> hard to kill with control-C) on my system using spa_ws with standard
>> settings. I tried both UP and SMP. I may be doing something wrong or
>> perhaps don't understand what you mean by a console lock up.
>
> Switching from one vt to another receives hardly any response.
Aah. Virtual terminals. I was using Gnome terminals under X.
>
> This is especially visible in spa_no_frills, and spa_ws recovers from this
> lockup somewhat and starts exhibiting this problem as a choking behavior.
>
> Running '# top d.1 (then shift T)' on another vt shows this choking behavior
> as the proc gets boosted.
>
>> When you say "less than the timeslice" how much smaller do you mean?
>
> This depends on your machine's performance. On my 400MhzP2 UP 128MB, w/
> spa_no_frills default settings, looping eatm 9999 takes 63ms per eat and
> causes the rest of the system to be starved. Raising kb to 19999 takes
> 126ms which is greater than the default 120ms timeslice and causes no system
> starvation.
>
> What numbers do you get?
For 9999 I get 20ms. I have 1GB of memory and no swapping is taking
place but with only 128MB it's possible that your system is swapping and
that could make the effect more pronounced.
But anyway, based on the evidence, I think the problem is caused by the
fact that the eatm tasks are running to completion in less than one time
slice without sleeping and this means that they never have their
priorities reassessed. The reason that spa_ebs doesn't demonstrate the
problem is that it uses a smaller time slice for the first time slice
that a task gets. The reason that it does this is that it gives newly
forked processes a fairly high priority and if they're left to run for a
full 120 msecs at that high priority they can hose the system. Having a
shorter first time slice gives the scheduler a chance to reassess the
task's priority before it does much damage.
The reason that the other schedulers don't have this strategy is that I
didn't think that it was necessary. Obviously I was wrong and should
extend it to the other schedulers. It's doubtful whether this will help
a great deal with spa_no_frills as it is pure round robin and doesn't
reassess priorities except when nice changes of the task changes
policies. This is one good reason not to use spa_no_frills on
production systems. Perhaps you should consider creating a child
scheduler on top of it that meets your needs?
Anyway, an alternative (and safer) way to reduce the effects of this
problem (while your waiting for me to do the above change) is to reduce
the size of the time slice. The only bad effects of doing this is that
you'll do slightly worse (less than 1%) on kernbench.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Anthony Liguori @ 2006-04-09 2:57 UTC (permalink / raw)
To: balrogg, qemu-devel
In-Reply-To: <fb249edb0604081221w1228728hc7c885892d9da7de@mail.gmail.com>
andrzej zaborowski wrote:
> 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.
>
No, it supports all three. Works quite well for new X drivers. If you
search the wacom-devel archives you'll find a link to the docs for the
Wacom driver.
It does kind of suck though that you have to manually configure your X
server. I looked at a number of tablets and they all seem to be serial
or undocumented.
Regards,
Anthony Liguori
> 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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Anthony Liguori @ 2006-04-09 2:55 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082112030.8325@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> 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?
>
http://www.cs.utexas.edu/users/aliguori/qemu-wacom-2.tgz but as I
mentioned earlier, YMMV.
Regards,
Anthony Liguori
> Ciao,
> Dscho
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Anthony Liguori @ 2006-04-09 2:54 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082054320.8169@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> 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 :-(
>
The USB version of the wacom tablet is not documented. Only the older
serial tablets are.
Regards,
Anthony Liguori
>> 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
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
^ 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.