* [Xenomai-core] Xenomai as module changing bzImage
From: Rodrigo Rosenfeld Rosas @ 2006-03-08 17:33 UTC (permalink / raw)
To: xenomai-core
Hi Philippe,
I disabled the kernel .config support, recompiled the kernel with latest ipipe
patch and rebooted my system (Xenomai configured as a module).
Then I downloaded last svn Xenomai. Compiled it (after correcting drvlib.c of
rtdm skin) and noted that it has changed the kernel bzImage too, besides
building the modules. Although I can use the new Xenomai modules without
rebooting my system, I can not understand why should bzImage change. Have you
any idea?
Thanks in advance,
Rodrigo.
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com
^ permalink raw reply
* Re: [patch 23/28] scsi cd: VariRec, GigaRec and PowerRec as user
From: Jeff Garzik @ 2006-03-08 17:30 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: James Bottomley, akpm, linux-scsi, T.Maguin, axboe
In-Reply-To: <20060308154532.GJ7301@parisc-linux.org>
Matthew Wilcox wrote:
> On Wed, Mar 08, 2006 at 09:12:06AM -0600, James Bottomley wrote:
>
>>On Wed, 2006-03-08 at 00:14 -0800, akpm@osdl.org wrote:
>>
>>>From: Thomas Maguin <T.Maguin@web.de>
>>
>>>This patch allows normal users to eectute some Plextor drives
>>>commands:
>>>
>>>- Hide CD-R
>>>- SingleSession
>>>- SpeedRead
>>>- PowerRec
>>>- VariRec
>>>- GigaRec
>>>
>>
>>This one just isn't safe. We can't add vendor specific commands to the
>>permissions table because they mean different things to different
>>vendors ... get mode on one could be halt and catch fire on another, so
>>the whole concept of safety via command verification is lost.
>
>
> Thanks for NAKing this one again, James. I'm a bit disappointed akpm
> picked it up given that I explained how unsafe it was when it was posted:
> http://marc.theaimsgroup.com/?l=linux-scsi&m=113976322621230&w=2
I NAK'd it as well, for obvious reasons...
Jeff
^ permalink raw reply
* Re: [MIPS] Always pass -msoft-float.
From: Jan-Benedict Glaw @ 2006-03-08 17:38 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <S8133817AbWCHRGj/20060308170640Z+412@ftp.linux-mips.org>
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
On Wed, 2006-03-08 17:06:32 +0000, linux-mips@linux-mips.org <linux-mips@linux-mips.org> wrote:
> Author: Ralf Baechle <ralf@linux-mips.org> Wed Mar 8 17:14:49 2006 +0000
> Commit: 36981cd8fd95a584ca93364b55a3916f9ee7ba13
> Branch: master
>
> Some people still haven't heared that fp in the kernel is forbidden.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Hi Ralf!
Is there any chance that you'd also include the diff in these emails?
Maybe that's not a good idea for merges from Linus' repo, though:-)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: policycoreutils latest diffs.
From: Stephen Smalley @ 2006-03-08 17:29 UTC (permalink / raw)
To: Daniel J Walsh
Cc: Christopher J. PeBenito, Ivan Gyurdiev, Joshua Brindle, SE Linux
In-Reply-To: <1140703334.21179.38.camel@moss-spartans.epoch.ncsc.mil>
On Thu, 2006-02-23 at 09:02 -0500, Stephen Smalley wrote:
> On Wed, 2006-02-22 at 13:23 -0500, Daniel J Walsh wrote:
> > audit2allow -
> >
> > Added (-R/--reference) to audit2allow. This basically greps through
> > reference policy and finds all matches for a particular
> > access. Then outputs them. It attempts to find the best match. This
> > makes updating reference policy a lot easier.
> >
> > Changed load_policy to be looked at regardless of the granted flag.
>
> Is this to catch reloads that occur in permissive mode?
> Going forward, you should be able to key off the new audit messages
> added by Steve Grubb for policy reloads, as they will indicate when a
> reload actually occurred (vs. just a permission check for them).
>
> > Add some checks to semanage and seobject.py to turn off processing on
> > non MLS/MCS machines.
> > (These are untested on a Non MLS/MCS machine, since I do not have access.)
>
> Doesn't quite work yet.
>
> # semanage login -l
> Login Name SELinux User
>
> Traceback (most recent call last):
> File "/usr/sbin/semanage", line 219, in ?
> OBJECT.list(heading)
> File "/usr/lib/python2.4/site-packages/seobject.py", line 375, in list
> print "%-25s %-25s %-25s" % (k, ddict[k][0])
> TypeError: not enough arguments for format string
>
> That one is easy to fix:
> --- seobject.py.0 2006-02-23 08:54:12.000000000 -0500
> +++ seobject.py 2006-02-23 08:54:16.000000000 -0500
> @@ -372,7 +372,7 @@ class loginRecords(semanageRecords):
> if heading:
> print "\n%-25s %-25s\n" % ("Login Name", "SELinux User")
> for k in keys:
> - print "%-25s %-25s %-25s" % (k, ddict[k][0])
> + print "%-25s %-25s" % (k, ddict[k][0])
>
> class seluserRecords(semanageRecords):
> def __init__(self):
>
> Then login -l works, but:
> # semanage login -a sds
> libsemanage.validate_handler: MLS is disabled, but MLS range was found for Unix user sds
> libsemanage.validate_handler: seuser mapping [sds -> (user_u, )] is invalid
> libsemanage.dbase_llist_iterate: could not iterate over records
> /usr/sbin/semanage: Could not add login mapping for sds
>
> So it looks like semanage (util) is passing libsemanage an empty string
> rather than a NULL?
I updated to the latest version of this patch from Fedora CVS, worked
around the two issues for MLS-disabled, and committed. Dropped the
fixfiles diff as it seems to be broken (try fixfiles check /boot).
I think that the audit2allow -R code will need further generalization
(e.g. location of policy devel files is presently hardcoded into the
script) for other distributions.
I verified that semanage login -l and semanage login -a sds worked on a
FC4 system (non-MLS, no python audit bindings), and it appeared to work
and syslog'd the audit message (but the record appears from "python:"
rather than "semanage").
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: git-svn, tree moves, and --no-stop-on-copy
From: Matthias Urlichs @ 2006-03-08 17:02 UTC (permalink / raw)
To: git
In-Reply-To: <20060307220837.GB27397@nowhere.earth>
Hi, Yann Dirson wrote:
> "svn switch --relocate" does not seem to be of any help. Switching
> manually .git/git-svn/tree/ to the new repository location does not
> help either, since I must obviously update to r166 in that case, and
> then a further "git-svn fetch" fails because it does not find
> .git/git-svn/revs/166 aleady imported.
>
> Any idea as to how to get the work done ?
You can manually edit the .git/corr file. Simply add an entry for #166
that has your reorganized (if necessary) head's SHA1.
--
Matthias Urlichs
^ permalink raw reply
* [PATCH] Fix MPC8548CDS rebooting procedure
From: Haruki Dai-r35557 @ 2006-03-08 17:22 UTC (permalink / raw)
To: linuxppc-dev
This patch fixes the MPC8548 CDS rebooting procedure.
Without this patche, issuing reboot from shell doesn't reboot the
machine.=20
Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
---
arch/ppc/syslib/ppc85xx_setup.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
8f095006923385c3546165b0e10d73d3e057c120
diff --git a/arch/ppc/syslib/ppc85xx_setup.c
b/arch/ppc/syslib/ppc85xx_setup.c
index e4dda43..45b1b2b 100644
--- a/arch/ppc/syslib/ppc85xx_setup.c
+++ b/arch/ppc/syslib/ppc85xx_setup.c
@@ -115,6 +115,11 @@ mpc85xx_early_serial_map(void)
void
mpc85xx_restart(char *cmd)
{
+#ifdef CONFIG_MPC8548
+ volatile unsigned int *rstcr;
+ u32 *pMem =3D (u32*) ioremap((BOARD_CCSRBAR + 0xe00b0),0x100);
+ *pMem =3D 0x2; /* Set HRESET_REQ flag */
+#endif
local_irq_disable();
abort();
}
--=20
1.2.4
^ permalink raw reply related
* [Xenomai-core] Error on rtdm skin with --enable-dox-doc
From: Rodrigo Rosenfeld Rosas @ 2006-03-08 17:21 UTC (permalink / raw)
To: xenomai-core
Hi Jan,
When compiling svn xenomai I noticed the following error with --enable-dox-doc
switch:
CC [M] kernel/xenomai/skins/rtdm/drvlib.o
kernel/xenomai/skins/rtdm/drvlib.c:1513:1: error: unterminated #ifdef
Best Regards,
Rodrigo.
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: David Howells @ 2006-03-08 17:19 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Alan Cox, David Howells, torvalds, akpm, mingo, linux-arch,
linuxppc64-dev, linux-kernel
In-Reply-To: <20060308154157.GI7301@parisc-linux.org>
Matthew Wilcox <matthew@wil.cx> wrote:
> > That might be worth an example with an if() because PPC will do this and
> > if its a read with a side effect (eg I/O space) you get singed..
>
> PPC does speculative memory accesses to IO? Are you *sure*?
Can you do speculative reads from frame buffers?
> # define smp_read_barrier_depends() do { } while(0)
What's this one meant to do?
> Port space is deprecated though. PCI 2.3 says:
That's sort of irrelevant for the here. I still need to document the
interaction.
> Since memory write transactions may be posted in bridges anywhere
> in the system, and I/O writes may be posted in the host bus bridge,
I'm not sure whether this is beyond the scope of this document. Maybe the
document's scope needs to be expanded.
David
^ permalink raw reply
* Re: NCQ general question
From: Jeff Garzik @ 2006-03-08 17:17 UTC (permalink / raw)
To: Louis-David Mitterrand; +Cc: Linux RAID Mailing List
In-Reply-To: <20060308165108.GA19567@apartia.fr>
Louis-David Mitterrand wrote:
> On Sun, Mar 05, 2006 at 02:29:15AM -0500, Jeff Garzik wrote:
>
>>Raz Ben-Jehuda(caro) wrote:
>>
>>>Is NCQ supported when setting the controller to JBOD instead of using HW
>>>raid?
>>
>>1) The two have nothing to do with each other
>>
>>2) It sounds like you haven't yet read
>>http://linux-ata.org/faq-sata-raid.html
>
>
> Hello,
>
> Do you plan on updating your AHCI NCQ patch found in
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/archive/
> It no longer applies cleanly to the latest 2.6.15.x kernel.
No, but, Jens Axboe and Tejun Heo will have a better version.
Jeff
^ permalink raw reply
* Re: [PATCH] realtime-preempt patch-2.6.15-rt19 compile error (was: realtime-preempt patch-2.6.15-rt18 issues)
From: Rui Nuno Capela @ 2006-03-08 17:15 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Jan Altenberg, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]
Hi,
Still got the blues whenever I try to unplug a usb-storage stick on -rt20 ;)
usb 2-1: new full speed USB device using ohci_hcd and address 2
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
Vendor: USB 2.0 Model: Flash Disk Rev: 2.00
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 2031616 512-byte hdwr sectors (1040 MB)
sda: Write Protect is off
sda: Mode Sense: 0b 00 00 08
sda: assuming drive cache: write through
SCSI device sda: 2031616 512-byte hdwr sectors (1040 MB)
sda: Write Protect is off
sda: Mode Sense: 0b 00 00 08
sda: assuming drive cache: write through
sda: sda1
sd 0:0:0:0: Attached scsi removable disk sda
usb-storage: device scan complete
usb 2-1: USB disconnect, address 2
slab error in kmem_cache_destroy(): cache `scsi_cmd_cache': Can't free all
objects
[<c0141d1e>] kmem_cache_destroy+0x66/0xdb (8)
[<c020487c>] scsi_destroy_command_freelist+0x4e/0x5a (12)
[<c02054eb>] scsi_host_dev_release+0x4b/0x6e (12)
[<c01eaca7>] device_release+0x14/0x39 (12)
[<c019d07f>] kobject_cleanup+0x3e/0x5e (4)
[<c019d09f>] kobject_release+0x0/0x8 (8)
[<e053278c>] usb_stor_control_thread+0x0/0x183 [usb_storage] (8)
[<c019d7ce>] kref_put+0x3a/0x44 (4)
[<e05328ee>] usb_stor_control_thread+0x162/0x183 [usb_storage] (12)
[<c0272dc1>] schedule+0xd4/0xf5 (32)
[<c01226bf>] kthread+0x63/0x8f (20)
[<c012265c>] kthread+0x0/0x8f (12)
[<c0100d39>] kernel_thread_helper+0x5/0xb (16)
BR
--
rncbc aka Rui Nuno Capela
rncbc@rncbc.org
[-- Attachment #2: config-2.6.15.6-rt20.0.gz --]
[-- Type: application/x-gzip-compressed, Size: 9785 bytes --]
[-- Attachment #3: dmesg-2.6.15.6-rt20.0.gz --]
[-- Type: application/x-gzip-compressed, Size: 5156 bytes --]
^ permalink raw reply
* [PATCH] compat. ifconf: fix limits
From: Randy.Dunlap @ 2006-03-08 17:16 UTC (permalink / raw)
To: netdev, linux-fsdevel; +Cc: Alexandra.Kossovsky, ak, akpm, torvalds
From: Randy Dunlap <rdunlap@xenotime.net>
A recent change to compat. dev_ifconf() in fs/compat_ioctl.c
causes ifconf data to be truncated 1 entry too early when copying it
to userspace. The correct amount of data (length) is returned,
but the final entry is empty (zero, not filled in).
The for-loop 'i' check should use <= to allow the final struct
ifreq32 to be copied. I also used the ifconf-corruption program
in kernel bugzilla #4746 to make sure that this change does not
re-introduce the corruption.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
fs/compat_ioctl.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- linux-2616-rc5.orig/fs/compat_ioctl.c
+++ linux-2616-rc5/fs/compat_ioctl.c
@@ -446,7 +446,7 @@ static int dev_ifconf(unsigned int fd, u
ifr = ifc.ifc_req;
ifr32 = compat_ptr(ifc32.ifcbuf);
for (i = 0, j = 0;
- i + sizeof (struct ifreq32) < ifc32.ifc_len && j < ifc.ifc_len;
+ i + sizeof (struct ifreq32) <= ifc32.ifc_len && j < ifc.ifc_len;
i += sizeof (struct ifreq32), j += sizeof (struct ifreq)) {
if (copy_in_user(ifr32, ifr, sizeof (struct ifreq32)))
return -EFAULT;
---
^ permalink raw reply
* Re: [PATCH rc5-mm] pids: kill PIDTYPE_TGID
From: Eric W. Biederman @ 2006-03-08 16:19 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Andrew Morton, linux-kernel, Ingo Molnar, Paul E. McKenney,
Linus Torvalds
In-Reply-To: <440EED04.57FF5594@tv-sign.ru>
Oleg Nesterov <oleg@tv-sign.ru> writes:
> Eric W. Biederman wrote:
>>
>> Oleg Nesterov <oleg@tv-sign.ru> writes:
>>
>> > depends on
>> >
>> > pidhash-dont-count-idle-threads.patch
>> > pidhash-kill-switch_exec_pids.patch
>> >
>> > otherwise (I think) it is orthogonal to all tref/proc changes.
>>
>> You also depend on your recent change to call __unhash_process
>> under the sighand lock. Since the ->tgrp is protected by
>> the sighand lock.
>
> Actually now I think it depends only on yours
> pidhash-kill-switch_exec_pids.patch
>
> This change (call __unhash_process under the sighand lock) does not
> touch __unhash_process() itself, it only moves the callsite. So this
> patch can go before or after this change. However it needs other
> patches from -mm to avoid rejects.
Agreed. I misread the code and didn't see that we had the tasklist_lock where
you did the list_add.
>> > This patch kills PIDTYPE_TGID pid_type thus saving one hash table
>> > in kernel/pid.c and speeding up subthreads create/destroy a bit.
>> > It is also a preparation for the further tref/pids rework.
>> >
>> > This patch adds 'struct list_head tgrp' to 'struct task_struct'
>> > instead. Note that ->tgrp need not to be rcu safe.
>>
>> Is there a reason for this? I think at least proc could easily
>> take advantage of an rcu safe implementation.
>>
>> Hmm. At the moment proc is only taking the tasklist_lock during
>> traversal so we may have a problem with the list_add anyway.
>
> tasklist or ->sighand is enough to do threads traversal. Yes,
> adding _rcu suffix allows us to do it under rcu_read_lock().
> However the thread group will not be stable during this traversal,
> we can miss some newly created thread or hit an already unhashed
> one.
Right so if what we are doing is needs to be atomic we can't drop
the lock. Which makes sense.
> Note also, that this loop:
>
> t = task;
> do {
> ...
> t = next_thread(t);
> } while (t != task);
>
> requires that task->tgrp is stable (I mean, 'task' must not be
> unhashed during this loop). And I can't see how this is possible
> unless we take ->sighand or tasklist_lock or task == current.
>
> Eric, I know nothing about proc/, so the question is: do you want
> me to add _rcu right now, or do you think it's better to do this
> later?
Let's add the manipulations right now, that way we have the option
to convert the users that can take advantage of it.
> grepping for next_thread in proc/ I have the feeling that we can
> convert the code from:
>
> read_lock(tasklist);
> if (pid_alive(task)) {
> do ... while (t != task);
> }
> read_unlock(tasklist);
>
> to:
>
> rcu_read_lock();
> if (lock_task_sighand(task)) {
> ...
> unlock_task_sighand(task);
> }
> rcu_read_unlock();
>
> But again, I don't understand this code.
For proc we don't even need the lock_task_sighand. It is purely best
effort. The more we can remove lock contention from proc the harder it
will be for a user space application to trigger long lock hold
times.
>> Also could we name the member not ->tgrp but ->threads?
>> I keep half expecting tgrp to be a number, and have a hard
>> time not mispelling it tpgrp.
>
> Agreed. I also started with 'threads' name, but we already have
> 'struct thread_struct thread' in the task_struct. So may be
> we could name it thread_group? I am rather agnostic and have nothing
> against 'threads', will resend this patch after yours decision.
Ok. Let's go with thread_group. It isn't a frequently used field
so as long as the name doesn't get terribly long things will work,
and thread_group is still much shorter than it's current name :)
Eric
^ permalink raw reply
* [PATCH] task: RCU protect task->usage
From: Eric W. Biederman @ 2006-03-08 16:39 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, Oleg Nesterov, Paul E. McKenney, Ingo Molnar,
William Irwin, Roland McGrath
Cleanup of task_struct does not happen when it's reference count drops to
zero, instead cleanup happens when release_task is called. Tasks can only
be looked up via rcu before release_task is called. All rcu protected members
of task_struct are freed by release_task.
Therefore we can move call_rcu from put_task_struct into release_task.
And we can modify release_task to not immediately release the reference
count but instead have it call put_task_struct from the function it gives
to call_rcu.
The end result:
- get_task_struct is safe in an rcu context where we have just looked
up the task.
- put_task_struct simplifies into it's old pre rcu self.
This reorganization also makes put_task_struct uncallable from modules
as it is not exported but it does not appear to be called from any
modules so this should not be an issue, and is triviall fixed.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
include/linux/sched.h | 4 +---
kernel/exit.c | 7 ++++++-
kernel/sched.c | 7 -------
3 files changed, 7 insertions(+), 11 deletions(-)
0147f1b21f737305af237aa1ad1f03b9fb94dac8
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 37a5d3c..2856f52 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -908,12 +908,10 @@ extern void free_task(struct task_struct
extern void __put_task_struct(struct task_struct *tsk);
#define get_task_struct(tsk) do { atomic_inc(&(tsk)->usage); } while(0)
-extern void __put_task_struct_cb(struct rcu_head *rhp);
-
static inline void put_task_struct(struct task_struct *t)
{
if (atomic_dec_and_test(&t->usage))
- call_rcu(&t->rcu, __put_task_struct_cb);
+ __put_task_struct(t);
}
/*
diff --git a/kernel/exit.c b/kernel/exit.c
index 2a7928a..806a667 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -127,6 +127,11 @@ static void __exit_signal(struct task_st
}
}
+static void delayed_put_task_struct(struct rcu_head *rhp)
+{
+ put_task_struct(container_of(rhp, struct task_struct, rcu));
+}
+
void release_task(struct task_struct * p)
{
int zap_leader;
@@ -163,7 +168,7 @@ repeat:
write_unlock_irq(&tasklist_lock);
proc_flush_task(p);
release_thread(p);
- put_task_struct(p);
+ call_rcu(&p->rcu, delayed_put_task_struct);
p = leader;
if (unlikely(zap_leader))
diff --git a/kernel/sched.c b/kernel/sched.c
index be211df..d901d1b 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -188,13 +188,6 @@ static inline unsigned int task_timeslic
#define task_hot(p, now, sd) ((long long) ((now) - (p)->last_ran) \
< (long long) (sd)->cache_hot_time)
-void __put_task_struct_cb(struct rcu_head *rhp)
-{
- __put_task_struct(container_of(rhp, struct task_struct, rcu));
-}
-
-EXPORT_SYMBOL_GPL(__put_task_struct_cb);
-
/*
* These are the runqueue data structures:
*/
--
1.2.2.g709a-dirty
^ permalink raw reply related
* [PATCH] task: Make task list manipulations RCU safe.
From: Eric W. Biederman @ 2006-03-08 16:42 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, Oleg Nesterov, Paul E. McKenney, Ingo Molnar,
William Irwin, Roland McGrath
While we can currently walk through thread groups, process groups, and
sessions with just the rcu_read_lock, this opens the door to walking
the entire task list.
We already have all of the other RCU guarantees so there is no cost
in doing this, this should be enough so that proc can stop taking the
tasklist lock during readdir.
prev_task was killed because it has no users, and using it will
miss new tasks when doing an rcu traversal.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
fs/exec.c | 2 +-
include/linux/sched.h | 3 +--
kernel/exit.c | 2 +-
kernel/fork.c | 2 +-
4 files changed, 4 insertions(+), 5 deletions(-)
51621c1a347edd8935a80fdf4c78840e03be5e03
diff --git a/fs/exec.c b/fs/exec.c
index d961639..c01150e 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -713,7 +713,7 @@ static int de_thread(struct task_struct
attach_pid(current, PIDTYPE_PID, current->pid);
attach_pid(current, PIDTYPE_PGID, current->signal->pgrp);
attach_pid(current, PIDTYPE_SID, current->signal->session);
- list_add_tail(¤t->tasks, &init_task.tasks);
+ list_add_tail_rcu(¤t->tasks, &init_task.tasks);
current->parent = current->real_parent = leader->real_parent;
leader->parent = leader->real_parent = child_reaper;
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 2856f52..e6fde1a 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1187,8 +1187,7 @@ extern void wait_task_inactive(task_t *
#define remove_parent(p) list_del_init(&(p)->sibling)
#define add_parent(p) list_add_tail(&(p)->sibling,&(p)->parent->children)
-#define next_task(p) list_entry((p)->tasks.next, struct task_struct, tasks)
-#define prev_task(p) list_entry((p)->tasks.prev, struct task_struct, tasks)
+#define next_task(p) list_entry(rcu_dereference((p)->tasks.next), struct task_struct, tasks)
#define for_each_process(p) \
for (p = &init_task ; (p = next_task(p)) != &init_task ; )
diff --git a/kernel/exit.c b/kernel/exit.c
index 806a667..47add40 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -56,7 +56,7 @@ static void __unhash_process(struct task
detach_pid(p, PIDTYPE_PGID);
detach_pid(p, PIDTYPE_SID);
- list_del_init(&p->tasks);
+ list_del_rcu(&p->tasks);
__get_cpu_var(process_counts)--;
}
diff --git a/kernel/fork.c b/kernel/fork.c
index d0eebc2..e7eef2e 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1210,7 +1210,7 @@ static task_t *copy_process(unsigned lon
attach_pid(p, PIDTYPE_PGID, process_group(p));
attach_pid(p, PIDTYPE_SID, p->signal->session);
- list_add_tail(&p->tasks, &init_task.tasks);
+ list_add_tail_rcu(&p->tasks, &init_task.tasks);
__get_cpu_var(process_counts)++;
}
attach_pid(p, PIDTYPE_TGID, p->tgid);
--
1.2.2.g709a-dirty
^ permalink raw reply related
* Re: AW: [Xenomai-core] Fundamental Questions
From: Christopher Stone @ 2006-03-08 17:13 UTC (permalink / raw)
To: xenomai
In-Reply-To: <5D63919D95F87E4D9D34FF7748CE2C2A20688E@ARVMAIL1.mra.roland-man.biz>
[-- Attachment #1: Type: text/plain, Size: 11029 bytes --]
In light of the desire for support below, would the Xenomai team consider listing companies capable of commercial support on their website, or create another mailing list for us to announce commercial offerings around Xenomai. I am prepared to contribute to Xenomai in order to receive this privilege.
Sorry for discussing commercial issues on your mailing list. If it makes it any better, we are a very small company, just trying to make a living, not a big corporate conglomerate.
As a final point, I believe Xenomai is very well positioned to become very popular and "future proof". I believe the next frontier for Linux is industrial grade Linux, or Linux on the factory floor and Xenomai will end up the technology of choice to make that happen. Contrary to many opinions I have heard, I beleve the rt-preempt work done by Ingo Molnar will enhance Xenomai and not replace it. I also think the break from RTAI was very smart as it has given you the flexibility to move Xenomai in the direction it needs to go. The recent releases have made Xenomai ready for the commercial world. So, kudos to the Xenomai team. You guys are proving to be great leaders with the right technology at the right time.
Cheers,
Chris Stone.
Roderik_Wildenburg@domain.hid wrote:
Dear Jan,
thank you for taking time to answer my questions and
sorry for the delayed response, but I have been busy
with some other work.
Please find my follow-up questions inserted in the text.
> >
> > 1.)
> > Essentially the question deals with the problem, how long a
> Xenomai task in secondary mode can be delayed by normal Linux tasks.
> > In detail : we plan to to have a lot of "near realtime"
> ethernet communication from within Xenomai using the normal
> Linux network stack (calling the normal socket API). The
> question now is, how our network communication is influenced
> by other Linux tasks performing also network communication,
> let´s say an FTP transfer ?
>
> Depending on the "normal" networking load, you will suffer
> from more or less frequent (indeterministic) packet delays.
Do you have an idea about the dimension weare talking about :
less than a millisecond, few milliseconds, seconds, or is the
delay complete indeterministic ?
> Xenomai will not improve this in any way. If your task in
> secondary mode tries to send some data and requires to take a
> networking lock currently held by another Linux task, it can
> take a real long time until this request is completed.
But at least, after a (linux-)systemcall (from what task ever) finished,
Xenomai gets controll back before any other linux task, isn´t it ?
This means : between systemcalls a rescheduling back to Xenomai is performed
or isn´t it ??
Sorry for the next stupid question, but what is a network lock. With what kind of
action a task can lock the complete stack ? And how long could it block the stack ?
Could you give me an example for better understanding ?
> This
> gets better with PREEMPT_RT but still remains non-RT because
> the Linux networking stack is not designed for hard real-time.
>
Next stupid question : what is PREEMPT_RT ? Is this kernel 2.6 or is it the
Monta Vista approach for real time (making the kernel more preemtable) ?
>
> If you communication can be soft-RT, you could indeed avoid
> the separation - but you will then have to live with the side
> effects. All you can do then is try to lower the number of
> deadline misses by keeping the standard network traffic low
> and managing the bandwidth of the participants (the Linux
> network stack has some support for QoS, at least
> 2.6 I think).
>
> BTW, as long as your network is not separated or you have no
> control over the traffic arriving at your system, picking the
> Linux stack in favour of RTnet (which is compatible with
> non-RT networks) is indeed generally recommended. This way
> you keep indeterministic load away from the real-time subsystem.
>
Unfortunatelly we don´t want to limit non realtime traffic, we just
want to make shure, that deterministic traffic has a higher priority
than non RT traffic (like in other RTOS like vxWorks).
Indeterministic traffic should get just the leftover bandwith.
What do you mean with : "Rtnet is compatible with non-RT networks" ?
I thought RTnet uses a time slice mechanism and therefore could not be
mixed with systems transmitting when ever they want. Do you refer to VNICs ?
> >
> > I have created a scheduling scenario and I would ask you to
> have a look on it and to tell me whether it is correct or
> not. Thank you !
> > An corresponding question about this scheduling is : are there
> > differences between a 2.4 and 2.6 Linux kernel ? (for our PowerPC
> > plattform we intend to use the 2.4 kernel for performance reasons)
> >
> > Scheduling scenario :
> > (I hope formating is not destroyed by email transfer)
> >
> > Time moves downwards
> >
> > v-Xenomai
> > v-Linux kernel
> > v-Linux processes
> >
> > l1 Linux task1 running
> > s1 < l1 Linux task1 makes systemcall
> > s1 Linux task1 systemcall processed
> > ------------- Linux scheduling
> > l2 Linux task2 starts to run
> > s2 < l2 Linux task2 makes systemcall
> > s2 Linux task2 systemcall processed
> > +++++++++++++ Xenomai scheduling
> > x3 Xenomai task3 starts to run => primary mode
> > x3 > s3 Xenomai task3 makes systemcall => secondary mode
> > s3 Xenomai task3 systemcall processed
> > ------------- Linux scheduling => Xenomai task preemted
>
> This preemption will only happen if the target Linux task has
> a higher priority or the Xenomai task on secondary mode has
> to block on some resource to be become free. As I sketched
> above, this can actually happen in the network stack.
What do you mean with "higher priority" ? I thought Xenomai has
a higher priority than anything else in the linux system.
Could you give mean example about the resource (related to network
communication) s3 could wait for ?
>
> > s1 Linux task1 systemcall processed
> > s1 > l1 Linux task1 systemcall ready => Linux task1
> continues
> > l1 Linux task1 continues
> > ------------- Linux scheduling
> > s2 Linux task2 systemcall processed
> > s2 > l2 Linux task2 systemcall ready => Linux task2
> continues
> > l2 Linux task2 continues
> > ------------- Linux scheduling => Xenomai Task3 systemcall
> continued
> > s3 Xenomai Task3 systemcall continued
> > x3 < s3 Xenomai Task3 systemcall ready => Xenomai
> Task contiunes
> > x3 but has been delayed by normal Linux tasks
> >
> >
> > 2.)
> > This question is not so crucial, but nevertheless interesting :
> > Who are the people behind Xenomai (I did not find anything
> about this on the Xenomai webpage), what is their background
> (University, Company)and who impels /sponsors the Xenomai
> development (University, Company, Community)?
> > I think I "identified" at least 2 core developers :
> Philippe Gerum and Gilles Chanteperdrix, but I don´t know
> very much more.
>
> I can add my/our own profile here: working at the university
> of Hannover (Real-Time Systems Group) with and on Xenomai to
> use it on mobile service robots and to do research on
> real-time security and industrial automation. Our institute
> is currently developing a larger robotic software framework
> on top of it. Primarily, we see Xenomai as a mature platform
> for doing real-time with Linux, i.e. as a very useful tool.
>
> > The background for this question is, to get a feeling, how
> future-proof the xenomai development is. As far as I can see
> open source projects often die or stall when the initiators
> decide that "growing flowers" is a much more pleasant job ;-).
> >
>
> We had to decide last year which way to go for our future
> platforms, also with potential industrial/commercial usage in
> mind (e.g.
> proprietary real-time algorithms as user-space applications).
> Based on our experience with the RTAI (> 4 years), my own
> insight into RTAI/fusion (Xenomai predecessor), and the
> status of PREEMPT_RT, we selected fusion (now Xenomai) as the
> most matured and future-proven one.
>
> Xenomai is enjoying an increasing acceptance in industry. Our
> industry partners e.g. are either planning to start new with
> Xenomai or port over from other RT-extensions - of course
> encouraged by our own good experience. I talked to a lot of
> smaller and real large companies over the last months,
> specifically here in Germany, that started new
> automation/embedded projects on top of Linux/Xenomai (as
> usual, most of their activities remain non-public -
> unfortunately). They are convinced of the future of this project.
>
> Moreover, I believe that Xenomai has a very healthy
> community. We have a quite active crowd of contributors and
> "plain" users. There is definitely more than one person
> knowing the internals of the system (as in many projects,
> there is still one person knowing them best...). And the code
> is also well documented (exceptions apart).
>
> No one can safely predict what will happen to a project when
> one of the main contributors stops working on it. But given
> the number of "advanced" Xenomai users already at this
> comparably early project stage, I'm convinced it would even
> survive such an exceptional scenario, i.e.
> it has reached a critical mass. But I have no indications
> that Philippe or Gilles will become gardeners. ;)
>
> This said, the best thing one can do as a long-term user of
> an open source project is to support its development actively by
>
> o promoting it (yes, it can already be that simple) o
> reporting problems o fixing minor bugs and posting the fixes
> o contributing new features and enhancements (drivers, board support,
> API extensions, ...)
> o or directly funding the development of such enhancements
>
> >
> > Thank you for taking time to answer these questions, which
> are interesting to others too, I think !?
> >
>
> Hope I was able to provide you some helpful details and arguments.
>
Yes, you did ! Thank you very much !
Things you said about the interest of larger companies, the widespread
knowledgement and code maturity sounds quite good to me.
Form your mentioning of "industrial partners" I conclude you are working with
or for companies also, not just for your universty.
So i would like to know whether you also offer external consultations ?
Just in case, we want to make shure that things, we plan to do are possible
with Xenomai.
Best Regards
Roderik
_______________________________________________
Xenomai-core mailing list
Xenomai-core@domain.hid
https://mail.gna.org/listinfo/xenomai-core
Christopher Stone
Principal
Sombrio Systems Inc.
www.openembedded.biz
613-831-1892
[-- Attachment #2: Type: text/html, Size: 12488 bytes --]
^ permalink raw reply
* [U-Boot-Users] I2C eeprom utilities
From: Wolfgang Denk @ 2006-03-08 17:10 UTC (permalink / raw)
To: u-boot
In-Reply-To: <440F0C1C.20907@sbcglobal.net>
In message <440F0C1C.20907@sbcglobal.net> you wrote:
>
> > I ported and enabled the eeprom commands to u-boot.
...
> > idea? How to generate this bin file? Also, the "imd"
> > command is not working properly on my set up.
...
> Only last few bytes are written in flash after a sequential write block?
No, not flash, but an EEPROM on the I2C bus.
> Usually indicates that the flash bus has a SMALLER bus width support
> (i.e., 8 or 16-bit) and software operation is performing 32-bit
> operations instead.
No.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Q: Why do mountain climbers rope themselves together?
A: To prevent the sensible ones from going home.
^ permalink raw reply
* [U-Boot-Users] I2C eeprom utilities
From: Wolfgang Denk @ 2006-03-08 17:09 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060308163943.21311.qmail@web30513.mail.mud.yahoo.com>
In message <20060308163943.21311.qmail@web30513.mail.mud.yahoo.com> you wrote:
>
> I ported and enabled the eeprom commands to u-boot.
> From the readme file, it expects a bin file to be
> loaded into ram and then using the "eeprom write"
> command we should be able to program the eeprom.
> => tftp 100000 eeprom.bin
> => md 100000
> => eeprom write 100000 0 100
> => eeprom read 150000 0 100
> => md 150000
> However, when I try the above and check the eeprom
> content only the last few bytes are programmed. Any
> idea? How to generate this bin file? Also, the "imd"
> command is not working properly on my set up.
Then you misconfigured your EEPROM interface (address length, page
size, ...)
> I am using u-boot version 1.1.2 on a custom board with
> mpc8541 cpu.
I wonder why everybody seems so eager to use old code...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Landru! Guide us!
-- A Beta 3-oid, "The Return of the Archons", stardate 3157.4
^ permalink raw reply
* Re: [Qemu-devel] build problems with linux usb support?
From: Johannes Schindelin @ 2006-03-08 17:08 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20060308165520.GB18882@narn.hozed.org>
Hi,
On Wed, 8 Mar 2006, Troy Benjegerdes wrote:
> /afs/scl.ameslab.gov/user/troy/src/qemu-cvs/usb-linux.c:30:
> /usr/include/asm-generic/div64.h:54:3: #error do_div() does not yet
> support the C64
You really try to make QEmu run on a C64? Wow!
;-) Sorry, could not resist,
Dscho
^ permalink raw reply
* Re: USB icon question
From: Greg KH @ 2006-03-08 17:07 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <440EF480.8040009@nethere.com>
On Wed, Mar 08, 2006 at 07:13:04AM -0800, Keith Lee wrote:
> All:
> I apologize for taking up your time; but, I have a quick question.
> Whenever I plug my mp3 player to my Linux PC, the hdd_mount.png icon
> appears. I would like to change this icon to another png file. How can
> I do that with a popup device icon? I right click on the icon but it
> doesn't allow me to change anything.
That's a distro and window-manager specific thing. Please ask one of
those groups instead, there's nothing we do from the kernel in regards
to icons :)
good luck,
greg k-h
-------------------------------------------------------
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\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: detecting squashfs volumes
From: Greg KH @ 2006-03-08 17:07 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060308165836.GA18525@danisch.de>
On Wed, Mar 08, 2006 at 05:58:36PM +0100, Hadmut Danisch wrote:
> Hi,
>
> I'd like to have CDROMs (and other block devices) with a squashfs
> volume (not a squashfs file on a ISO filesystem) automatically mounted
> when putting it into the drive, just with normal ISO cdroms.
>
> The main problem seems to be that vol_id does not detect anything
> about squashfs volumes, no label, no UUID, no filesystem type. The
> reasons seems to be squashfs itself, as far as I know it does not
> contain any label or UUID.
>
> What would it take to have squashfs extended to support these
> features? What would I have to tell the squashfs maintainer?
This exact email would be a good start :)
good luck,
greg k-h
-------------------------------------------------------
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\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: David Howells @ 2006-03-08 17:04 UTC (permalink / raw)
To: Alan Cox
Cc: David Howells, torvalds, akpm, mingo, linux-arch, linuxppc64-dev,
linux-kernel
In-Reply-To: <20060308145506.GA5095@devserv.devel.redhat.com>
Alan Cox <alan@redhat.com> wrote:
> [For information on bus mastering DMA and coherency please read ....]
>
> sincee have a doc on this
Documentation/pci.txt?
> The use of volatile generates poorer code and hides the serialization in
> type declarations that may be far from the code.
I'm not sure what you mean by that.
> Is this true of IA-64 ??
Are you referring to non-temporal loads and stores?
> > +There are some more advanced barriering functions:
>
> "barriering" ... ick, barrier.
Picky:-)
> Should clarify local ordering v SMP ordering for locks implied here.
Do you mean explain what each sort of lock does?
> > + (*) inX(), outX():
> > +
> > + These are intended to talk to legacy i386 hardware using an alternate bus
> > + addressing mode. They are synchronous as far as the x86 CPUs are
>
> Not really true. Lots of PCI devices use them. Need to talk about "I/O space"
Which bit is not really true?
David
^ permalink raw reply
* Re: ACL on NFS, how make it work?
From: Marco Gaiarin @ 2006-03-08 17:04 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Andreas Gruenbacher, Marius Aamodt Eriksen, Jeff Sedlak, nfs
In-Reply-To: <20060306152340.GA31408@fieldses.org>
Mandi! J. Bruce Fields
In chel di` si favelave...
> Actually I got one other NFS/XFS ACL complaint recently, and confirmed
> that with current kernels I'm able to get and set ext3 ACL's over NFS,
> and get and set XFS ACL's locally, but I can't use XFS ACL's over NFS.
> Which is odd--on a first glance it looks like the two filesystems expor=
t
> posix acl's through the same interface, etc. I haven't had the chance
> to figure out what's going on yet....
If i can do something to debug that, say me.
Eg, better to recompile the server kernel with *client* ACL NFSv3
support?=20
--=20
dott. Marco Gaiarin GNUPG Key ID: 240A3D66
Associazione ``La Nostra Famiglia'' http://www.sv.lnf.it=
/
Polo FVG - Via della Bont=E0, 7 - 33078 - San Vito al Tagliamento (=
PN)
marco.gaiarin(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
that extends applications into web and mobile media. Attend the live webc=
ast
and join the prime developer group breaking into this new coding territor=
y!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: raid 5 corruption
From: goldfita @ 2006-03-08 17:01 UTC (permalink / raw)
To: Molle Bestefich; +Cc: linux-raid
>Molle Bestefich wrote:
>Todd <goldfita@signalsguru.net> wrote:
>> The strangest thing happened the other day. I booted my machine
>> and the permissions were all messed up. I couldn't access many
>> files as root which were owned by root. I couldnt' run common
>> programs as root or a standard user.
>Odd, have you found out why?
>What was the first error you saw?
>> So I restarted and it wouldn't mount my raid drive (raid 5, 5 disks).
>> I tried doing it manually from the livecd, and it's telling me it
>> can't mount with only 2 disks.
>Is that because the kernel found only 2/5 physical disks,
>or because MD thinks that they're out-of-date?
>> I tried to force with four drives and it claims there's no
>> superblock for sda3.
>Try mdadm --assemble --force again, but exclude sda3 and
>assemble the array using the 4 other drives instead?
>You might want to run mdadm to query the superblock on each device.
>You can post the output to this list so others will be able to see
>which of your drives are considered 'freshest' by MD etc.
>> There's nothing wrong with my disks. I can mount the boot partition.
>One doesn't imply the other. And since you don't tell where the boot
>partition resides, it hardly seems relevant to your RAID devices..
>> It's fine as far as I can tell. Does anyone know what's going on?
>> Has anyone else experienced this?
>> I have had problems in the past with other machines.
>> One time a redhat machine locked up in X.
>Yeah, I've had X lock up on me quite a lot.
>> I don't know if it was just X or the kernel.
>Probably the graphics driver.
>> I restarted and it couldn't find the root i-node.
>> It may have been correctable, but I just reinstalled.
>> It seems strange that windows can crash on me every day and
>> it still starts right back up. (I still have 98.)
>> But linux seems to have more fragile file systems.
>Windows' flushing policy is a LOT more sane than Linux'.
>That's probably why you'll rarely get corrupted filesystems
>with Windows, and often with Linux.
>Like you, I've had filesystem corruption after system crashes
>happen to me with Linux quite a lot, and never (even though
>it crashes much more often) with Windows.
>My guess is that the Linux kernel folks are more concerned with
>a .01% improvement in performance than with your data and that's
>why the policy is as it is.. But I could easily be wrong, so take
>it with a grain of salt.
You're going to hate this, but it works now. I have no idea what I did.
I accidentally assembled the array on md0 instead of md2 with force. It
synced the array with sda3 (which I think I corrupted messing with
reiserfsck). After that I was able to assemble the array on md2 as usual.
That's about all I can tell you. It seems my files are all intact,
permissions and everything. Thanks.
-Todd
^ permalink raw reply
* detecting squashfs volumes
From: Hadmut Danisch @ 2006-03-08 16:58 UTC (permalink / raw)
To: linux-hotplug
Hi,
I'd like to have CDROMs (and other block devices) with a squashfs
volume (not a squashfs file on a ISO filesystem) automatically mounted
when putting it into the drive, just with normal ISO cdroms.
The main problem seems to be that vol_id does not detect anything
about squashfs volumes, no label, no UUID, no filesystem type. The
reasons seems to be squashfs itself, as far as I know it does not
contain any label or UUID.
What would it take to have squashfs extended to support these
features? What would I have to tell the squashfs maintainer?
regards
Hadmut
-------------------------------------------------------
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\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* [Qemu-devel] Patch day
From: Ulrich Hecht @ 2006-03-08 16:57 UTC (permalink / raw)
To: fabrice, paul; +Cc: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 923 bytes --]
Hi!
Here's the current lot of patches from the SuSE QEMU package. As we have
now arrived at the point where patches start to conflict with each
other, I would be very grateful if at least some of these went into the
next release.
qemu-0.7.0-binfmt.patch: some enhancements to the qemu-binfmt-conf.sh
script
qemu-0.7.1-armfpaex.patch: proper FPA exception generation for arm-user
targets
qemu-0.7.1-jobsignals.patch: handle SIGTTOU/SIGTTIN/SIGTSTP; makes job
control work
qemu-0.7.1-syscalls.patch: implements acct, uselib, syslog, mincore,
madvise, readahead, clock_gettime; I have not extensively checked these
for correctness, but from experience I can say that with this patch
applied a lot of breakage vanishes
qemu-0.8.0-ia64.patch: Itanium host fixes by Andreas Schwab
qemu-nwfpe-cpsr.patch: fixes ARM FPA CPSR updates; same as posted before,
but fixed to work with qemu-0.7.1-armfpaex.patch
CU
Uli
[-- Attachment #2: qemu-0.7.0-binfmt.patch --]
[-- Type: text/x-diff, Size: 4630 bytes --]
--- qemu-binfmt-conf.sh
+++ qemu-binfmt-conf.sh
@@ -2,38 +2,46 @@
# enable automatic i386/ARM/SPARC/PPC program execution by the kernel
# load the binfmt_misc module
-/sbin/modprobe binfmt_misc
+
+if test ! -e /proc/sys/fs/binfmt_misc/register
+then
+ /sbin/modprobe binfmt_misc
+ mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
+fi
# probe cpu type
cpu=`uname -m`
case "$cpu" in
- i386|i486|i586|i686|i86pc|BePC)
+ i386|i486|i586|i686|i86pc|BePC|x86_64)
cpu="i386"
;;
"Power Macintosh"|ppc|ppc64)
cpu="ppc"
;;
- armv4l)
+ armv[4-9]*l)
cpu="arm"
;;
+ sparc*)
+ cpu="sparc"
+ ;;
esac
# register the interpreter for each cpu except for the native one
if [ $cpu != "i386" ] ; then
- echo ':i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/local/bin/qemu-i386:' > /proc/sys/fs/binfmt_misc/register
- echo ':i486:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x06\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/local/bin/qemu-i386:' > /proc/sys/fs/binfmt_misc/register
+ echo ':i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-i386:' > /proc/sys/fs/binfmt_misc/register
+ echo ':i486:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x06\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-i386:' > /proc/sys/fs/binfmt_misc/register
fi
if [ $cpu != "arm" ] ; then
- echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/local/bin/qemu-arm:' > /proc/sys/fs/binfmt_misc/register
- echo ':armeb:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/local/bin/qemu-armeb:' > /proc/sys/fs/binfmt_misc/register
+ echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm:' > /proc/sys/fs/binfmt_misc/register
+ echo ':armeb:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-armeb:' > /proc/sys/fs/binfmt_misc/register
fi
if [ $cpu != "sparc" ] ; then
- echo ':sparc:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x02:\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/local/bin/qemu-sparc:' > /proc/sys/fs/binfmt_misc/register
+ echo ':sparc:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x02:\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-sparc:' > /proc/sys/fs/binfmt_misc/register
fi
if [ $cpu != "ppc" ] ; then
- echo ':ppc:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x14:\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/local/bin/qemu-ppc:' > /proc/sys/fs/binfmt_misc/register
+ echo ':ppc:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x14:\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-ppc:' > /proc/sys/fs/binfmt_misc/register
fi
if [ $cpu != "mips" ] ; then
- echo ':mips:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/local/bin/qemu-mips:' > /proc/sys/fs/binfmt_misc/register
- echo ':mipsel:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/local/bin/qemu-mipsel:' > /proc/sys/fs/binfmt_misc/register
+ echo ':mips:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-mips:' > /proc/sys/fs/binfmt_misc/register
+ echo ':mipsel:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-mipsel:' > /proc/sys/fs/binfmt_misc/register
fi
[-- Attachment #3: qemu-0.7.1-armfpaex.patch --]
[-- Type: text/x-diff, Size: 3572 bytes --]
--- linux-user/main.c
+++ linux-user/main.c
@@ -339,18 +339,54 @@
{
TaskState *ts = env->opaque;
uint32_t opcode;
+ int rc;
/* we handle the FPU emulation here, as Linux */
/* we get the opcode */
opcode = ldl_raw((uint8_t *)env->regs[15]);
- if (EmulateAll(opcode, &ts->fpa, env->regs) == 0) {
+ if ((rc=EmulateAll(opcode, &ts->fpa, env->regs)) == 0) { /* illegal instruction */
info.si_signo = SIGILL;
info.si_errno = 0;
info.si_code = TARGET_ILL_ILLOPN;
info._sifields._sigfault._addr = env->regs[15];
queue_signal(info.si_signo, &info);
- } else {
+ } else if (rc < 0) { /* FP exception */
+ int arm_fpe=0;
+ /* translate softfloat flags to FPSR flags */
+ if(-rc & float_flag_invalid) arm_fpe |= BIT_IOC;
+ if(-rc & float_flag_divbyzero) arm_fpe |= BIT_DZC;
+ if(-rc & float_flag_overflow) arm_fpe |= BIT_OFC;
+ if(-rc & float_flag_underflow) arm_fpe |= BIT_UFC;
+ if(-rc & float_flag_inexact) arm_fpe |= BIT_IXC;
+
+ FPSR fpsr = ts->fpa.fpsr;
+ //printf("fpsr 0x%x, arm_fpe 0x%x\n",fpsr,arm_fpe);
+
+ if(fpsr & (arm_fpe << 16)) /* exception enabled? */
+ {
+ info.si_signo = SIGFPE;
+ info.si_errno = 0;
+ /* ordered by priority, least first */
+ if(arm_fpe & BIT_IXC) info.si_code = TARGET_FPE_FLTRES;
+ if(arm_fpe & BIT_UFC) info.si_code = TARGET_FPE_FLTUND;
+ if(arm_fpe & BIT_OFC) info.si_code = TARGET_FPE_FLTOVF;
+ if(arm_fpe & BIT_DZC) info.si_code = TARGET_FPE_FLTDIV;
+ if(arm_fpe & BIT_IOC) info.si_code = TARGET_FPE_FLTINV;
+ info._sifields._sigfault._addr = env->regs[15];
+ queue_signal(info.si_signo, &info);
+ }
+ else
+ env->regs[15] += 4;
+
+ /* accumulate unenabled exceptions */
+ if((!(fpsr & BIT_IXE)) && (arm_fpe & BIT_IXC)) fpsr |= BIT_IXC;
+ if((!(fpsr & BIT_UFE)) && (arm_fpe & BIT_UFC)) fpsr |= BIT_UFC;
+ if((!(fpsr & BIT_OFE)) && (arm_fpe & BIT_OFC)) fpsr |= BIT_OFC;
+ if((!(fpsr & BIT_DZE)) && (arm_fpe & BIT_DZC)) fpsr |= BIT_DZC;
+ if((!(fpsr & BIT_IOE)) && (arm_fpe & BIT_IOC)) fpsr |= BIT_IOC;
+ ts->fpa.fpsr=fpsr;
+ } else { /* everything OK */
/* increment PC */
env->regs[15] += 4;
}
--- target-arm/nwfpe/fpa11.c
+++ target-arm/nwfpe/fpa11.c
@@ -161,6 +161,8 @@
fpa11->initflag = 1;
}
+ set_float_exception_flags(0, &fpa11->fp_status);
+
if (TEST_OPCODE(opcode,MASK_CPRT))
{
//fprintf(stderr,"emulating CPRT\n");
@@ -190,6 +192,11 @@
}
// restore_flags(flags);
+ if(nRc == 1 && get_float_exception_flags(&fpa11->fp_status))
+ {
+ //printf("fef 0x%x\n",float_exception_flags);
+ nRc=-get_float_exception_flags(&fpa11->fp_status);
+ }
//printf("returning %d\n",nRc);
return(nRc);
[-- Attachment #4: qemu-0.7.1-jobsignals.patch --]
[-- Type: text/x-diff, Size: 698 bytes --]
--- linux-user/signal.c
+++ linux-user/signal.c
@@ -341,10 +341,15 @@
k = &sigact_table[sig - 1];
handler = k->sa._sa_handler;
if (handler == TARGET_SIG_DFL) {
+ if (sig == TARGET_SIGTSTP || sig == TARGET_SIGTTIN || sig == TARGET_SIGTTOU) {
+ kill(getpid(),SIGSTOP);
+ return 0;
+ } else
/* default handler : ignore some signal. The other are fatal */
if (sig != TARGET_SIGCHLD &&
sig != TARGET_SIGURG &&
- sig != TARGET_SIGWINCH) {
+ sig != TARGET_SIGWINCH &&
+ sig != TARGET_SIGCONT) {
force_sig(sig);
} else {
return 0; /* indicate ignored */
[-- Attachment #5: qemu-0.7.1-syscalls.patch --]
[-- Type: text/x-diff, Size: 3856 bytes --]
--- linux-user/arm/syscall_nr.h
+++ linux-user/arm/syscall_nr.h
@@ -259,4 +259,5 @@
/* 254 for set_thread_area */
/* 255 for get_thread_area */
/* 256 for set_tid_address */
+#define TARGET_NR_clock_gettime (263)
#define TARGET_NR_utimes (269)
--- linux-user/syscall.c
+++ linux-user/syscall.c
@@ -207,6 +207,7 @@
#define __NR_sys_getdents __NR_getdents
#define __NR_sys_getdents64 __NR_getdents64
#define __NR_sys_rt_sigqueueinfo __NR_rt_sigqueueinfo
+#define __NR_sys_syslog __NR_syslog
#if defined(__alpha__) || defined (__ia64__) || defined(__x86_64__)
#define __NR__llseek __NR_lseek
@@ -228,6 +229,7 @@
_syscall2(int,sys_statfs,const char *,path,struct kernel_statfs *,buf)
_syscall2(int,sys_fstatfs,int,fd,struct kernel_statfs *,buf)
_syscall3(int,sys_rt_sigqueueinfo,int,pid,int,sig,siginfo_t *,uinfo)
+_syscall3(int,sys_syslog,int,type,char*,bufp,int,len)
#ifdef __NR_exit_group
_syscall1(int,exit_group,int,error_code)
#endif
@@ -241,6 +243,7 @@
extern int setresgid(gid_t, gid_t, gid_t);
extern int getresgid(gid_t *, gid_t *, gid_t *);
extern int setgroups(int, gid_t *);
+extern int uselib(const char*);
static inline long get_errno(long ret)
{
@@ -1895,7 +1898,9 @@
goto unimplemented;
case TARGET_NR_acct:
- goto unimplemented;
+ ret = get_errno(acct(path((const char*)arg1)));
+ break;
+
case TARGET_NR_umount2:
ret = get_errno(umount2((const char *)arg1, arg2));
break;
@@ -2207,7 +2212,9 @@
ret = get_errno(readlink(path((const char *)arg1), (char *)arg2, arg3));
break;
case TARGET_NR_uselib:
- goto unimplemented;
+ ret = get_errno(uselib(path((const char*)arg1)));
+ break;
+
case TARGET_NR_swapon:
ret = get_errno(swapon((const char *)arg1, arg2));
break;
@@ -2322,7 +2329,9 @@
ret = do_socketcall(arg1, (int32_t *)arg2);
break;
case TARGET_NR_syslog:
- goto unimplemented;
+ ret = get_errno(sys_syslog((int)arg1, (char*)arg2, (int)arg3));
+ break;
+
case TARGET_NR_setitimer:
{
struct target_itimerval *target_value = (void *)arg2;
@@ -3116,11 +3125,14 @@
goto unimplemented;
#ifdef TARGET_NR_mincore
case TARGET_NR_mincore:
- goto unimplemented;
+ page_unprotect_range((void*)arg3, ((size_t)arg2 + TARGET_PAGE_SIZE - 1) / TARGET_PAGE_SIZE);
+ ret = get_errno(mincore((void*)arg1, (size_t)arg2, (unsigned char*)arg3));
+ break;
#endif
#ifdef TARGET_NR_madvise
case TARGET_NR_madvise:
- goto unimplemented;
+ ret = get_errno(madvise((void*)arg1, (size_t)arg2, (int)arg3));
+ break;
#endif
#if TARGET_LONG_BITS == 32
case TARGET_NR_fcntl64:
@@ -3169,7 +3181,8 @@
ret = get_errno(gettid());
break;
case TARGET_NR_readahead:
- goto unimplemented;
+ ret = get_errno(readahead((int)arg1, (off64_t)arg2, (size_t)arg3));
+ break;
#ifdef TARGET_NR_setxattr
case TARGET_NR_setxattr:
case TARGET_NR_lsetxattr:
@@ -3190,6 +3203,22 @@
case TARGET_NR_get_thread_area:
goto unimplemented_nowarn;
#endif
+#ifdef TARGET_NR_clock_gettime
+ case TARGET_NR_clock_gettime:
+ {
+ struct target_timespec* ttp = (struct target_timespec*)arg2;
+ struct timespec htp;
+ if(ttp) {
+ htp.tv_sec = tswapl(ttp->tv_sec);
+ htp.tv_nsec = tswapl(ttp->tv_nsec);
+ ret = get_errno(clock_gettime((clockid_t)arg1, &htp));
+ ttp->tv_sec = tswapl(htp.tv_sec);
+ ttp->tv_nsec = tswapl(htp.tv_nsec);
+ } else
+ ret = get_errno(clock_gettime((clockid_t)arg1, NULL));
+ break;
+ }
+#endif
default:
unimplemented:
gemu_log("qemu: Unsupported syscall: %d\n", num);
[-- Attachment #6: qemu-0.8.0-ia64.patch --]
[-- Type: text/x-diff, Size: 3702 bytes --]
---
Makefile.target | 3 ---
cpu-exec.c | 3 +--
dyngen.c | 6 ++++--
dyngen.h | 3 +++
linux-user/syscall.c | 2 +-
target-mips/exec.h | 4 ++++
6 files changed, 13 insertions(+), 8 deletions(-)
Index: Makefile.target
===================================================================
--- Makefile.target.orig 2006-03-07 02:12:48.000000000 +0100
+++ Makefile.target 2006-03-07 02:12:48.000000000 +0100
@@ -252,9 +252,6 @@ ifeq ($(findstring m68k, $(TARGET_ARCH)
LIBOBJS+=m68k-dis.o
endif
-ifeq ($(ARCH),ia64)
-OBJS += ia64-syscall.o
-endif
ifdef CONFIG_GDBSTUB
OBJS+=gdbstub.o
endif
Index: cpu-exec.c
===================================================================
--- cpu-exec.c.orig 2005-12-19 23:51:53.000000000 +0100
+++ cpu-exec.c 2006-03-07 02:12:48.000000000 +0100
@@ -1351,7 +1351,6 @@ int cpu_signal_handler(int host_signum,
#ifndef __ISR_VALID
/* This ought to be in <bits/siginfo.h>... */
# define __ISR_VALID 1
-# define si_flags _sifields._sigfault._si_pad0
#endif
int cpu_signal_handler(int host_signum, struct siginfo *info, void *puc)
@@ -1367,7 +1366,7 @@ int cpu_signal_handler(int host_signum,
case SIGSEGV:
case SIGBUS:
case SIGTRAP:
- if (info->si_code && (info->si_flags & __ISR_VALID))
+ if (info->si_code && (info->si_segvflags & __ISR_VALID))
/* ISR.W (write-access) is bit 33: */
is_write = (info->si_isr >> 33) & 1;
break;
Index: dyngen.c
===================================================================
--- dyngen.c.orig 2005-12-19 23:51:53.000000000 +0100
+++ dyngen.c 2006-03-07 02:14:36.000000000 +0100
@@ -2469,10 +2469,12 @@ fprintf(outfile,
);
#ifdef HOST_IA64
fprintf(outfile,
- " ia64_apply_fixes(&gen_code_ptr, ltoff_fixes, "
+ " {\n"
+ " extern char code_gen_buffer[];\n"
+ " ia64_apply_fixes(&gen_code_ptr, ltoff_fixes, "
"(uint64_t) code_gen_buffer + 2*(1<<20), plt_fixes,\n\t\t\t"
"sizeof(plt_target)/sizeof(plt_target[0]),\n\t\t\t"
- "plt_target, plt_offset);\n");
+ "plt_target, plt_offset);\n }\n");
#endif
/* generate some code patching */
Index: dyngen.h
===================================================================
--- dyngen.h.orig 2005-12-19 23:51:53.000000000 +0100
+++ dyngen.h 2006-03-07 02:12:48.000000000 +0100
@@ -420,6 +420,9 @@ static inline void ia64_apply_fixes (uin
}
ia64_imm22(fixup->addr, (long) vp - gp);
}
+ /* Keep code ptr aligned. */
+ if ((long) gen_code_ptr & 15)
+ gen_code_ptr += 8;
*gen_code_pp = gen_code_ptr;
}
Index: linux-user/syscall.c
===================================================================
--- linux-user/syscall.c.orig 2006-03-07 02:12:48.000000000 +0100
+++ linux-user/syscall.c 2006-03-07 02:12:48.000000000 +0100
@@ -1513,7 +1513,7 @@ int do_fork(CPUState *env, unsigned int
#endif
new_env->opaque = ts;
#ifdef __ia64__
- ret = clone2(clone_func, new_stack + NEW_STACK_SIZE, flags, new_env);
+ ret = __clone2(clone_func, new_stack + NEW_STACK_SIZE, flags, new_env);
#else
ret = clone(clone_func, new_stack + NEW_STACK_SIZE, flags, new_env);
#endif
Index: target-mips/exec.h
===================================================================
--- target-mips/exec.h.orig 2005-12-19 23:51:53.000000000 +0100
+++ target-mips/exec.h 2006-03-07 02:12:48.000000000 +0100
@@ -31,7 +31,11 @@ register double FT2 asm(FREG2);
#endif
#if defined (DEBUG_OP)
+#if defined (__ia64__)
+#define RETURN() __asm__ __volatile__("nop 0");
+#else
#define RETURN() __asm__ __volatile__("nop");
+#endif
#else
#define RETURN() __asm__ __volatile__("");
#endif
[-- Attachment #7: qemu-nwfpe-cpsr.patch --]
[-- Type: text/x-diff, Size: 3050 bytes --]
--- qemu-0.8.0/linux-user/main.c
+++ qemu-0.8.0/linux-user/main.c
@@ -346,7 +346,7 @@
/* we get the opcode */
opcode = ldl_raw((uint8_t *)env->regs[15]);
- if ((rc=EmulateAll(opcode, &ts->fpa, env->regs)) == 0) { /* illegal instruction */
+ if ((rc=EmulateAll(opcode, &ts->fpa, env)) == 0) { /* illegal instruction */
info.si_signo = SIGILL;
info.si_errno = 0;
info.si_code = TARGET_ILL_ILLOPN;
--- qemu-0.8.0/target-arm/nwfpe/fpa11.c
+++ qemu-0.8.0/target-arm/nwfpe/fpa11.c
@@ -36,7 +36,7 @@
unsigned int EmulateCPRT(const unsigned int);
FPA11* qemufpa=0;
-unsigned int* user_registers=0;
+CPUARMState* user_registers=0;
/* Reset the FPA11 chip. Called to initialize and reset the emulator. */
void resetFPA11(void)
@@ -137,7 +137,7 @@
}
/* Emulate the instruction in the opcode. */
-unsigned int EmulateAll(unsigned int opcode, FPA11* qfpa, unsigned int* qregs)
+unsigned int EmulateAll(unsigned int opcode, FPA11* qfpa, CPUARMState* qregs)
{
unsigned int nRc = 0;
// unsigned long flags;
--- qemu-0.8.0/target-arm/nwfpe/fpa11.h
+++ qemu-0.8.0/target-arm/nwfpe/fpa11.h
@@ -26,6 +26,8 @@
#include <stdio.h>
#include <errno.h>
+#include <cpu.h>
+
#define GET_FPA11() (qemufpa)
/*
@@ -33,7 +35,7 @@
* stack+task struct. Use the same method as 'current' uses to
* reach them.
*/
-extern unsigned int *user_registers;
+extern CPUARMState *user_registers;
#define GET_USERREG() (user_registers)
@@ -94,7 +96,7 @@
static inline unsigned int readRegister(unsigned int reg)
{
- return (user_registers[(reg)]);
+ return (user_registers->regs[(reg)]);
}
static inline void writeRegister(unsigned int x, unsigned int y)
@@ -102,34 +104,17 @@
#if 0
printf("writing %d to r%d\n",y,x);
#endif
- user_registers[(x)]=(y);
+ user_registers->regs[(x)]=(y);
}
static inline void writeConditionCodes(unsigned int x)
{
-#if 0
-unsigned int y;
-unsigned int ZF;
- printf("setting flags to %x from %x\n",x,user_registers[16]);
-#endif
- user_registers[16]=(x); // cpsr
- user_registers[17]=(x>>29)&1; // cf
- user_registers[18]=(x<<3)&(1<<31); // vf
- user_registers[19]=x&(1<<31); // nzf
- if(!(x&(1<<30))) user_registers[19]++; // nzf must be non-zero for zf to be cleared
-
-#if 0
- ZF = (user_registers[19] == 0);
- y=user_registers[16] | (user_registers[19] & 0x80000000) | (ZF << 30) |
- (user_registers[17] << 29) | ((user_registers[18] & 0x80000000) >> 3);
- if(y != x)
- printf("GODDAM SHIIIIIIIIIIIIIIIIT! %x %x nzf %x zf %x\n",x,y,user_registers[19],ZF);
-#endif
+ cpsr_write(user_registers,x,~CPSR_M);
}
#define REG_PC 15
-unsigned int EmulateAll(unsigned int opcode, FPA11* qfpa, unsigned int* qregs);
+unsigned int EmulateAll(unsigned int opcode, FPA11* qfpa, CPUARMState* qregs);
/* included only for get_user/put_user macros */
#include "qemu.h"
^ 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.