* Re: [linux-lvm] LVM over IP network
From: Zac Slade @ 2006-04-08 3:16 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <1144412972.44365b2c36361@mail.sify.com>
On Friday 07 April 2006 07:59, rarulselvan@sify.com wrote:
> I do understand that LVM and EVMS are quite useful for managing the disk
> space in given work station. So I am wondering if there is such thing as
> LVM over IP network ? so that I can maximize my disk usage. If not, what is
> my other choice ?
Why not? Using iSCSI or ATAoE you can export the extra space from each of the
system as devices that will appear to be block devices. From there you can
add them to a vg anytime you want. Just be careful how you do it because if
one of the systems goes off the network you will not have access to the data
from that drive. Also I'm not so sure how well LVM deals with having a drive
dissappear out from underneath it.
--
Zac Slade
krakrjak@volumehost.net
ICQ:1415282 YM:krakrjak AIM:ttyp99
^ permalink raw reply
* [ANNOUNCE] Mercurial 0.8.1 released
From: Bryan O'Sullivan @ 2006-04-08 3:26 UTC (permalink / raw)
To: linux-kernel
Version 0.8.1 of the Mercurial distributed revision control system is
now available. This release features numerous usability improvements,
performance enhancements, and bug fixes over previous releases.
More information about Mercurial, including information on downloading
sources and binaries can be found at:
http://www.selenic.com/mercurial/
The Mercurial mirror of Linus's kernel git tree is available at:
http://www.kernel.org/hg/linux-2.6/
Many thanks to Mercurial contributors and supporters for making the
continued rapid improvement of this software possible!
Major changes from 0.8 to 0.8.1:
- new extensions:
mq (manage a queue of patches, like quilt only better)
email (send changes as series of email patches)
- new command: merge (replaces "update -m")
- improved commands: log (--limit option added), pull/push ("-r" works
on specific revisions), revert (rewritten, much better)
- comprehensive hook support
- output templating added, supporting e.g. GNU changelog style
- Windows, Mac OS X: prebuilt binary packages, better support
- many reliability, performance, and memory usage improvements
For help, visit the web site or #mercurial on irc.freenode.net
--
Bryan O'Sullivan <bos@serpentine.com>
^ permalink raw reply
* Re: [PATCH] Enable 36-bit physical address on MIPS32R2 also
From: Sergei Shtylyov @ 2006-04-08 3:56 UTC (permalink / raw)
To: linux-mips; +Cc: Manish Lachwani, Jordan Crouse, Ralf Baechle
In-Reply-To: <4436C301.2060001@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 314 bytes --]
Hello.
PTEs in MIPS32R2 have the same layout for the 36-bit physical address case
as in MIPS32R1, according to the architecture manuals -- so, fix the #if's.
Not sure that we need that #if defined(CONFIG_CPU_MIPS32) at all though...
WBR, Sergei
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
[-- Attachment #2: MIPS32R2-36bit-phys-addr.patch --]
[-- Type: text/plain, Size: 4367 bytes --]
diff --git a/include/asm-mips/pgtable-32.h b/include/asm-mips/pgtable-32.h
index 4d6bc45..5f31351 100644
--- a/include/asm-mips/pgtable-32.h
+++ b/include/asm-mips/pgtable-32.h
@@ -116,7 +116,7 @@ static inline void pmd_clear(pmd_t *pmdp
pmd_val(*pmdp) = ((unsigned long) invalid_pte_table);
}
-#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32_R1)
+#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32)
#define pte_page(x) pfn_to_page(pte_pfn(x))
#define pte_pfn(x) ((unsigned long)((x).pte_high >> 6))
static inline pte_t
@@ -137,9 +137,9 @@ pfn_pte(unsigned long pfn, pgprot_t prot
#define pfn_pte(pfn, prot) __pte(((pfn) << (PAGE_SHIFT + 2)) | pgprot_val(prot))
#else
#define pte_pfn(x) ((unsigned long)((x).pte >> PAGE_SHIFT))
-#define pfn_pte(pfn, prot) __pte(((unsigned long long)(pfn) << PAGE_SHIFT) | pgprot_val(prot))
+#define pfn_pte(pfn, prot) __pte(((pfn) << PAGE_SHIFT) | pgprot_val(prot))
#endif
-#endif /* defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32_R1) */
+#endif /* defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32) */
#define __pgd_offset(address) pgd_index(address)
#define __pud_offset(address) (((address) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
@@ -202,7 +202,7 @@ pfn_pte(unsigned long pfn, pgprot_t prot
*/
#define PTE_FILE_MAX_BITS 27
-#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32_R1)
+#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32)
/* fixme */
#define pte_to_pgoff(_pte) (((_pte).pte_high >> 6) + ((_pte).pte_high & 0x3f))
#define pgoff_to_pte(off) \
diff --git a/include/asm-mips/pgtable-bits.h b/include/asm-mips/pgtable-bits.h
index 01e76e9..3aad751 100644
--- a/include/asm-mips/pgtable-bits.h
+++ b/include/asm-mips/pgtable-bits.h
@@ -33,7 +33,7 @@
* unpredictable things. The code (when it is written) to deal with
* this problem will be in the update_mmu_cache() code for the r4k.
*/
-#if defined(CONFIG_CPU_MIPS32_R1) && defined(CONFIG_64BIT_PHYS_ADDR)
+#if defined(CONFIG_CPU_MIPS32) && defined(CONFIG_64BIT_PHYS_ADDR)
#define _PAGE_PRESENT (1<<6) /* implemented in software */
#define _PAGE_READ (1<<7) /* implemented in software */
@@ -123,7 +123,7 @@
#endif
#endif
-#endif /* defined(CONFIG_CPU_MIPS32_R1) && defined(CONFIG_64BIT_PHYS_ADDR) */
+#endif /* defined(CONFIG_CPU_MIPS32) && defined(CONFIG_64BIT_PHYS_ADDR) */
#define __READABLE (_PAGE_READ | _PAGE_SILENT_READ | _PAGE_ACCESSED)
#define __WRITEABLE (_PAGE_WRITE | _PAGE_SILENT_WRITE | _PAGE_MODIFIED)
@@ -140,7 +140,7 @@
#define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_COW
#endif
-#if defined(CONFIG_CPU_MIPS32_R1) && defined(CONFIG_64BIT_PHYS_ADDR)
+#if defined(CONFIG_CPU_MIPS32) && defined(CONFIG_64BIT_PHYS_ADDR)
#define CONF_CM_DEFAULT (PAGE_CACHABLE_DEFAULT >> 3)
#else
#define CONF_CM_DEFAULT (PAGE_CACHABLE_DEFAULT >> 9)
diff --git a/include/asm-mips/pgtable.h b/include/asm-mips/pgtable.h
index 702a28f..925211d 100644
--- a/include/asm-mips/pgtable.h
+++ b/include/asm-mips/pgtable.h
@@ -85,7 +85,7 @@ extern void paging_init(void);
#define pte_none(pte) (!(pte_val(pte) & ~_PAGE_GLOBAL))
#define pte_present(pte) (pte_val(pte) & _PAGE_PRESENT)
-#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32_R1)
+#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32)
static inline void set_pte(pte_t *ptep, pte_t pte)
{
ptep->pte_high = pte.pte_high;
@@ -173,7 +173,7 @@ extern pgd_t swapper_pg_dir[PTRS_PER_PGD
* Undefined behaviour if not..
*/
static inline int pte_user(pte_t pte) { BUG(); return 0; }
-#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32_R1)
+#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32)
static inline int pte_read(pte_t pte) { return (pte).pte_low & _PAGE_READ; }
static inline int pte_write(pte_t pte) { return (pte).pte_low & _PAGE_WRITE; }
static inline int pte_dirty(pte_t pte) { return (pte).pte_low & _PAGE_MODIFIED; }
@@ -332,7 +332,7 @@ static inline pgprot_t pgprot_noncached(
*/
#define mk_pte(page, pgprot) pfn_pte(page_to_pfn(page), (pgprot))
-#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32_R1)
+#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32)
static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
{
pte.pte_low &= _PAGE_CHG_MASK;
^ permalink raw reply related
* Re: cross automount issue
From: Ian Kent @ 2006-04-08 3:47 UTC (permalink / raw)
To: Joe Pruett; +Cc: autofs
In-Reply-To: <Pine.LNX.4.64.0604062047510.13380@q7.q7.com>
On Thu, 6 Apr 2006, Joe Pruett wrote:
> maybe there is a better way to do this, so i'll lay out my plan first,
> then my problem, and then my solution.
>
> to avoid 100s or 1000s of nfs mounts i would like to have one mount per
> exported file system and then bind mounts (or symlinks) for each directory
> within each mount point. like so:
>
> real mounts:
> /disks/foo.0 -> foo:/0
> /disks/foo.1 -> foo:/1
> /disks/bar.0 -> bar:/0
>
> etc.
>
> and then bind mounts:
>
> /home/user -> /disks/foo.0/user
> /home/other -> /disks/foo.1/other
> /home/another -> /disks/bar.0/another
>
> now this kinda works, but since there is one global lock file for all
> automount daemons the first reference to /home/user will try to touch
> /disks/foo.0 and that will hang for 10 seconds waiting for the lock file.
> once the real mounts are done, things work well. and since there are a
> few thousand entries in /home it keeps the nfs mounts from getting out of
> control.
>
> so my solution would be to make one lock per daemon. that will keep each
> daemon happy and they won't interfere with each other.
>
> is that a reasonable idea? is there a better way to cope with this? i
> know that long ago you used to be able to do things like:
Another possibility is to disable the locking.
I have a patch to do this but you must be aware that you need to
make sure mounts' locking is not broken if you use it.
Ian
^ permalink raw reply
* Re: [PATCH 1/4] coredump: optimize ->mm users traversal
From: Roland McGrath @ 2006-04-08 3:51 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Andrew Morton, Eric W. Biederman, Ingo Molnar, Paul E. McKenney,
linux-kernel
In-Reply-To: <20060406220607.GA232@oleg>
This patch looks good to me.
Signed-off-by: Roland McGrath <roland@redhat.com>
Thanks,
Roland
^ permalink raw reply
* [PATCH 2.6.16] Shared interrupts sometimes lost
From: Neil Brown @ 2006-04-08 4:10 UTC (permalink / raw)
To: linux-kernel
Hi,
I've been having enormous fun just lately playing with my new Minitar
wireless cards - based on the RaLink 2560 chip set. I have a
couple of PCI cards that seem to work well, and a PCMCIA that mostly
works, but will lockup the computer under load, which isn't nice :-(
This is using the "legacy" rt2500 driver derived from the vendor
provided driver, rather than the newer rt2x00 which I cannot get to
work at all. These are all part of rt2400.sourceforge.net.
Anyway, it turns out that my lockup problem is actually a problem in
the Linux kernel rather than with the driver (though possibly aspects
of the driver make the situation worse). I have a patch, below,
which fixes my problem for me.
The problem is that after a while, the interrupts generated by the
card stop being handled by Linux, so the ISR routine in the driver
doesn't get called, and progress of all sorts stop. The fact that
this leads to a full system lockup is the fault of the driver, not
Linux. But Linux is definitely implicated in the loss of interrupts.
I can work around the problem using "irqpoll", but that is a bit
heavy handed, and shouldn't be needed.
This is my first real introduction to the IRQ handling code in Linux,
so please forgive any little errors. I'm fairly sure the big picture
is right, partly because the patch helps so much.
To explain what I think is happening, let me start with a very simple
case. A number of PCI devices (this one included) have a number of
events which can trigger an interrupt. The events which are current
are presented as bits in a register, and are ORed together (and
possibly masked by another register) to make the IRQ line.
When 1's are written to any bits in this register, it acknowledges
the event and clears the bit.
A typical code fragment is
events = read_register(INTERRUPTS);
write_register(INTERRUPTS, events);
... handle each 1 bits in events ....
This would normally clear all pending events and cause the interrupt
line to go low (or at least to not be asserted).
However there is room for a race here. If an event occurs between
the read and the write, then this will NOT de-assert the IRQ line.
It will remain asserted throughout.
Now if the IRQ is handled as an edge-triggered line (which I believe
they are in Linux), then losing this race will mean that we don't see
any more interrupts on this line.
This is a race that would be fairly hard to hit, and is easily fixed
by the driver. After handling all of 'events', it should read the
INTERRUPTS register again and see if there is anything more. I tried
this and it didn't fix my problem (though it might have made it
happen less often, I'm not certain).
In my particular case (and probably quite commonly with PCMCIA
cards), the IRQ line is shared:
10: 66178 XT-PIC yenta, yenta, ohci_hcd:usb2, ohci_hcd:usb3, ehci_hcd:usb4, eth0
So now the race is somewhat larger.
If yenta-1 handles its interrupt events and then another event
happens for yenta-1 before eth0 gets around to clearing its
interrupts, the shared IRQ line will remain asserted after all IRQ
handlers have been called, and so another edge will never be seen.
This race - with a shared IRQ line - cannot be handled within any one
driver. There needs to be some sort of end-to-end check.
In particular, the list of 'action' handlers needs to be called
repeatedly until a full pass has been made through all, and none of
them have reported that there was anything to do. Only then can we
be sure that the IRQ line has been de-asserted.
The following patch does that, and "works for me". It included a
kernel-parameter which allows me to disable the fix so I can test
that the fix really makes a difference. It does.
I am presenting this patch for comment at the moment rather than
inclusion. If it is generally acceptable, I'll remove the __setup
stuff and put a proper change-log at the top etc.
It might be appropriate to put a loop limit in so it doesn't more
than 1000 times or something, just in case someone claims to always
handle the interrupt. Is that needed?
Looking forward to your comments,
NeilBrown
------------------------------
Signed-off-by: Neil Brown <neilb@suse.de>
### Diffstat output
./kernel/irq/handle.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff ./kernel/irq/handle.c~current~ ./kernel/irq/handle.c
--- ./kernel/irq/handle.c~current~ 2006-04-08 13:26:46.000000000 +1000
+++ ./kernel/irq/handle.c 2006-04-08 13:27:05.000000000 +1000
@@ -73,23 +73,47 @@ irqreturn_t no_action(int cpl, void *dev
return IRQ_NONE;
}
+static int safeirq = 1;
+int __init unsafeirq_setup(char *str)
+{
+ safeirq = 0;
+ printk(KERN_INFO "IRQ safety-line removed - good luck\n");
+ return 1;
+}
+__setup("unsafeirq", unsafeirq_setup);
/*
* Have got an event to handle:
*/
fastcall int handle_IRQ_event(unsigned int irq, struct pt_regs *regs,
- struct irqaction *action)
+ struct irqaction *actionlist)
{
int ret, retval = 0, status = 0;
+ struct irqaction *action = actionlist;
+ int repeat=0;
if (!(action->flags & SA_INTERRUPT))
local_irq_enable();
do {
ret = action->handler(irq, action->dev_id, regs);
- if (ret == IRQ_HANDLED)
+ if (ret == IRQ_HANDLED) {
status |= action->flags;
+ repeat = 1;
+ }
retval |= ret;
action = action->next;
+ if (!action &&
+ repeat &&
+ safeirq &&
+ (actionlist->flags & SA_SHIRQ)) {
+ /* at least one handler on the list did something,
+ * and the interrupt is sharable, so give
+ * every handler another chance, incase a new event
+ * came in and is holding the irq line asserted.
+ */
+ action = actionlist;
+ repeat = 0;
+ }
} while (action);
if (status & SA_SAMPLE_RANDOM)
^ permalink raw reply
* Re: [Bluez-devel] SCO transparent transmission
From: Sowmya Gattupalli @ 2006-04-08 4:12 UTC (permalink / raw)
To: bluez-devel
In-Reply-To: <4436772F.6030300@csr.com>
[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]
Hey Steven...
For a CSR USB chip when the SCO mapping is over HCI is it possible to change
the voice settings to send PCM samples over the air?
On 4/7/06, Steven Singer <steven.singer@csr.com> wrote:
>
> Sowmya Gattupalli wrote:
> > On 4/4/06, Israel Guío <israzar@gmail.com> wrote:
> >> example, with 0x0063 as voice settings. I have tried it with my
> Bluetooth
> > How did u use CVSD when transmitting over sco?? [...]
>
> He was quite clear that he'd used voice settigns 0x0063. The last two
> bits indicate transparent coding and not CVSD.
>
> Israel, you need to be sure you're sending data at exactly the right
> average data rate. SCO links are synchronous and if you don't provide
> data at exactly the right rate then something somewhere in the
> system will have to insert or delete samples.
>
> It would also be helpful if you stated what chip and firmware version
> you were using.
>
> - Steven
> --
>
>
> To access the latest news from CSR copy this link into a web browser:
> http://www.csr.com/email_sig.php
>
>
> -------------------------------------------------------
> 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?cmdlnk&kid\x110944&bid$1720&dat\x121642
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
[-- Attachment #2: Type: text/html, Size: 2290 bytes --]
^ permalink raw reply
* [PATCH] sparse: gcc 4.1 warnings
From: Jeff Garzik @ 2006-04-08 4:14 UTC (permalink / raw)
To: linux-sparse
This patch kills the sparse warnings that appeared for me on FC5/x86-64,
which uses gcc 4.1.0.
Note this MAY OR MAY NOT be the right thing to do; I didn't audit each
location to see if checking the return value would be more appropriate.
Signed-off-by: Jeff Garzik <jeff@garzik.org>
diff --git a/compile-i386.c b/compile-i386.c
index d61652e..158b879 100644
--- a/compile-i386.c
+++ b/compile-i386.c
@@ -472,12 +472,12 @@ static inline void push_cstring(struct f
atom->string = str;
atom->label = label;
- add_ptr_list(&f->str_list, atom); /* note: _not_ atom_list */
+ (void) add_ptr_list(&f->str_list, atom); /* note: _not_ atom_list */
}
static inline void push_atom(struct function *f, struct atom *atom)
{
- add_ptr_list(&f->atom_list, atom);
+ (void) add_ptr_list(&f->atom_list, atom);
}
static void push_text_atom(struct function *f, const char *text)
@@ -518,7 +518,7 @@ static struct storage *stack_alloc(int n
f->stack_size += n_bytes;
f->pseudo_nr++;
- add_ptr_list(&f->pseudo_list, stor);
+ (void) add_ptr_list(&f->pseudo_list, stor);
return stor;
}
diff --git a/example.c b/example.c
index 7e30c22..42e64c1 100644
--- a/example.c
+++ b/example.c
@@ -230,7 +230,7 @@ static struct storage_hash *find_or_crea
if (!entry) {
entry = alloc_storage_hash(alloc_storage());
entry->pseudo = pseudo;
- add_ptr_list(listp, entry);
+ (void) add_ptr_list(listp, entry);
}
return entry;
}
@@ -460,7 +460,7 @@ static void mark_reg_dead(struct bb_stat
static void add_pseudo_reg(struct bb_state *state, pseudo_t pseudo, struct hardreg *reg)
{
output_comment(state, "added pseudo %s to reg %s", show_pseudo(pseudo), reg->name);
- add_ptr_list_tag(®->contains, pseudo, TAG_DIRTY);
+ (void) add_ptr_list_tag(®->contains, pseudo, TAG_DIRTY);
}
static struct hardreg *preferred_reg(struct bb_state *state, pseudo_t target)
diff --git a/lib.h b/lib.h
index a61b2dd..7c31dd2 100644
--- a/lib.h
+++ b/lib.h
@@ -168,17 +168,17 @@ static inline void concat_instruction_li
static inline void add_symbol(struct symbol_list **list, struct symbol *sym)
{
- add_ptr_list(list, sym);
+ (void) add_ptr_list(list, sym);
}
static inline void add_statement(struct statement_list **list, struct statement *stmt)
{
- add_ptr_list(list, stmt);
+ (void) add_ptr_list(list, stmt);
}
static inline void add_expression(struct expression_list **list, struct expression *expr)
{
- add_ptr_list(list, expr);
+ (void) add_ptr_list(list, expr);
}
#define hashval(x) ((unsigned long)(x))
diff --git a/linearize.c b/linearize.c
index f47bad9..6986517 100644
--- a/linearize.c
+++ b/linearize.c
@@ -1664,7 +1664,7 @@ static void add_asm_input(struct entrypo
rule->ident = ident;
rule->constraint = constraint;
use_pseudo(pseudo, &rule->pseudo);
- add_ptr_list(&insn->asm_rules->inputs, rule);
+ (void) add_ptr_list(&insn->asm_rules->inputs, rule);
}
static void add_asm_output(struct entrypoint *ep, struct instruction *insn, struct expression *expr,
@@ -1682,7 +1682,7 @@ static void add_asm_output(struct entryp
rule->ident = ident;
rule->constraint = constraint;
use_pseudo(pseudo, &rule->pseudo);
- add_ptr_list(&insn->asm_rules->outputs, rule);
+ (void) add_ptr_list(&insn->asm_rules->outputs, rule);
}
static pseudo_t linearize_asm_statement(struct entrypoint *ep, struct statement *stmt)
diff --git a/linearize.h b/linearize.h
index 5f021a3..fa37c8b 100644
--- a/linearize.h
+++ b/linearize.h
@@ -224,17 +224,17 @@ static inline int is_branch_goto(struct
static inline void add_bb(struct basic_block_list **list, struct basic_block *bb)
{
- add_ptr_list(list, bb);
+ (void) add_ptr_list(list, bb);
}
static inline void add_instruction(struct instruction_list **list, struct instruction *insn)
{
- add_ptr_list(list, insn);
+ (void) add_ptr_list(list, insn);
}
static inline void add_multijmp(struct multijmp_list **list, struct multijmp *multijmp)
{
- add_ptr_list(list, multijmp);
+ (void) add_ptr_list(list, multijmp);
}
static inline void *add_pseudo(struct pseudo_list **list, struct pseudo *pseudo)
@@ -263,7 +263,7 @@ static inline int bb_reachable(struct ba
static inline void add_pseudo_ptr(pseudo_t *ptr, struct pseudo_ptr_list **list)
{
- add_ptr_list(list, ptr);
+ (void) add_ptr_list(list, ptr);
}
static inline int has_use_list(pseudo_t p)
diff --git a/liveness.c b/liveness.c
index 8b0dfd8..5a8bb06 100644
--- a/liveness.c
+++ b/liveness.c
@@ -288,7 +288,7 @@ static void track_phi_uses(struct instru
continue;
def = phi->def;
assert(def->opcode == OP_PHISOURCE);
- add_ptr_list(&def->phi_users, insn);
+ (void) add_ptr_list(&def->phi_users, insn);
} END_FOR_EACH_PTR(phi);
}
diff --git a/parse.c b/parse.c
index 4339657..d2d24e1 100644
--- a/parse.c
+++ b/parse.c
@@ -278,7 +278,7 @@ static struct token *parse_enum_declarat
sym->initializer = expr;
sym->ctype.base_type = parent;
- add_ptr_list(&entries, sym);
+ (void) add_ptr_list(&entries, sym);
if (base_type != &bad_ctype) {
if (ctype->type == SYM_NODE)
diff --git a/storage.c b/storage.c
index acbc477..1b34e1e 100644
--- a/storage.c
+++ b/storage.c
@@ -52,7 +52,7 @@ struct storage_hash_list *gather_storage
struct storage_hash *hash;
FOR_EACH_PTR(storage_hash_table[i], hash) {
if (hash->bb == bb && hash->inout == inout)
- add_ptr_list(&list, hash);
+ (void) add_ptr_list(&list, hash);
} END_FOR_EACH_PTR(hash);
}
sort_hash_list(&list);
@@ -106,7 +106,7 @@ void add_storage(struct storage *storage
hash->pseudo = pseudo;
hash->inout = inout;
- add_ptr_list(listp, hash);
+ (void) add_ptr_list(listp, hash);
}
@@ -203,7 +203,7 @@ static struct storage * combine_storage(
FOR_EACH_PTR(src->users, usep) {
assert(*usep == src);
*usep = dst;
- add_ptr_list(&dst->users, usep);
+ (void) add_ptr_list(&dst->users, usep);
} END_FOR_EACH_PTR(usep);
/* Mark it unused */
diff --git a/storage.h b/storage.h
index c1822e5..fee106f 100644
--- a/storage.h
+++ b/storage.h
@@ -69,7 +69,7 @@ static inline struct storage_hash *alloc
struct storage **usep = &entry->storage;
*usep = s;
- add_ptr_list(&s->users, usep);
+ (void) add_ptr_list(&s->users, usep);
return entry;
}
^ permalink raw reply related
* Re: script binding for reiserfs?
From: Dongxu Ma @ 2006-04-08 4:16 UTC (permalink / raw)
To: Peter van Hardenberg; +Cc: reiserfs-list
In-Reply-To: <3395df770604071759y26ca8903s3c77efee45ba33ec@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]
On 4/8/06, Peter van Hardenberg <pvh@pvh.ca> wrote:
>
> Dongxu,
>
> Reaching into the filesystem itself for a project like this is not a very
> good idea. A wiki is a set of files -- let the filesystem do the hard work
> for you and use the standard API that is already in existence -- the VFS.
> You'll get all the benefits of the Reiser filesystem without having to break
> compatibility with other systems.
>
my own thought is that one can operate the filesystem, or at least query it
via programming interface, you know, introduce shell is really a bad idea.
There are already some examples on CPAN such as Filesys::Ext2.
I think a DBI/DBD interface to a Reiser-friendly file format is a really
> neat idea. You could create table rows as individual files within a
> directory and do foreign keys with links! I wonder what on-disk form would
> leverage Reiser4's dancing trees and intelligent allocation the most
> efficiently?
>
Yeah, I can store each field into a file, and creat view and table
structure from directory and links. With the help of reiserfs, I assume this
could be possible to try.
I must say though, there is no binding to the Reiser4 API, and the Namesys
> team is very busy right now working towards getting R4 included in the
> mainline kernel. Hopefully once they have achieved this, the more exciting
> development can continue.
>
2.6.16 is a big step;-P
As for your second question, my experience is strictly with R4, so someone
> else will have to comment on that issue.
>
Anyway, great help for me, thanks.
All the best,
> Peter van Hardenberg
>
>
> On 4/6/06, Dongxu Ma <dongxu.ma@gmail.com> wrote:
> >
> > Hi all,
> >
> > As reiserfs more and more popular, is there any binding package for use
> > in script languages? I did a search on Google and nothing found.
> > Curently I am thinking about writing a binding for Perl, which can
> > offer:
> > 1) script-level operation against reiserfs
> > 2) DBI && DBD for reiserfs binding to treat the fs as a database. My aim
> > is constructing a mid-and-small wiki directly on reiserfs without employing
> > any real database
> >
> > However, after some seeking on source. I got several issues:
> > 1) is there any so-called official userspace api exported?
> > On gentoo there is a package named progsreiserfs introducing an api set
> > under /usr/include/reiserfs, but I am not very sure if it is stable and the
> > project is still alive.
> >
> > 2) regarding reiser3, where could I start to port? since exporting
> > something in kernelspace is quite risky.
> >
> > Any advice and hint?
> >
> > --
> > Cheers, Dongxu
> > __END__
> > dongxu.wordpress.com
> > search.cpan.org/~dongxu <http://search.cpan.org/%7Edongxu>
> >
>
>
>
> --
> Peter van Hardenberg
> Victoria, BC, Canada
> "The wise man proportions his belief to the evidence." -- David Hume
>
--
Cheers, Dongxu
__END__
dongxu.wordpress.com
search.cpan.org/~dongxu
[-- Attachment #2: Type: text/html, Size: 4909 bytes --]
^ permalink raw reply
* Re: RT task scheduling
From: Vernon Mauery @ 2006-04-08 4:28 UTC (permalink / raw)
To: Steven Rostedt
Cc: Bill Huey, Darren Hart, Ingo Molnar, linux-kernel,
Thomas Gleixner, Stultz, John, Peter Williams, Siddha, Suresh B,
Nick Piggin
In-Reply-To: <1144465282.30689.62.camel@localhost.localdomain>
On Friday 07 April 2006 20:01, Steven Rostedt wrote:
> Hi Bill,
>
> I'm just catching up on this thread. Is your main concern that a High
> prio task is going to be unnecessary delayed because there's a lower RT
> task on the same CPU and time is needed to push it off to another CPU?
> It's late, so forgive me if this is a stupid question ;)
What I have gathered from this thread is that there are two important (and
partially conflicting) requirements for better real-time support.
1) Deterministic scheduling algorithms (SWSRPS). Basically, with uniprocessor
systems (or smp with a global run queue), it was really easy to say, run the
highest priority task in the queue. But when there are several queues that
are independent of each other, it is difficult. According to SWSRPS, nr_cpus
highest priority runnable tasks should _always_ be running (regardless of
which queue they are on). This might mean that there are longer latencies a)
to determine the nr_cpus highest priority tasks and b) because of cache
issues.
2) Maximum deterministic latency. A task should be able to say that if it
relinquishes the processor for now, MAX_LATENCY nanoseconds (or ticks or
whatever you want to measure time in) later, it will be back in time to meet
a deadline.
As I understand it, real time is all about determinism. But there are several
places where we have to focus on determinism to make it all behave as it
should.
Priority A > B > C
If a lower priority task C gets run just because it is the highest in that
CPU's run queue while there is a higher priority task B is sleeping while A
runs (on a 2 proc system), this is WRONG. But then again, we need to make
sure that we can determine the maximum latency to preempt C to run B and try
to minimize that.
Poof! More smoke in the air. I hope that clears it up.
--Vernon
> On Fri, 2006-04-07 at 16:36 -0700, Bill Huey wrote:
> > > Has this cleared some things up? If not, let me know what else needs
> > > clarification.
> >
> > Yes, but you should really work to clarify terminology. Is this better ?
>
> Goes both ways :)
>
> -- Steve
>
> PS. It's really good to see you back on LKML. I've missed your posts.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH]: kexec: framework and i386
From: Horms @ 2006-04-08 4:39 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: Magnus Damm, xen-devel
In-Reply-To: <4436809B.5040601@suse.de>
On Fri, Apr 07, 2006 at 05:09:15PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > Here is a first cut of kexec for dom0/xen, which will actually
> > kexec the physical machine from xen. The approach taken is
> > to move the architecture-dependant kexec code into a new hypercall.
>
> First you need some more security checks. On a first quick look it
> seems you can zap and takeover the whole machine from within a domU by
> kexec-booting the machine.
Yes, I think you are right, I had completely forgotten about that.
> Second I think we'll need a new kexec flag to indicate we'll go zap the
> physical machine, not the virtual machine. I'm looking into the later,
> and I think we'll be able to do both at some point in the future. Maybe
> it is enougth to care about dom0 (physical machine kexec) vs. domU
> (virtual machine kexec) only though. We certainly don't want allow
> domUs kexec the whole machine, and virtual machine kexec for dom0
> doesn't make that much sense given how tight xen and dom0 work hand-in-hand.
Sounds fine by me. The focus of what I was trying to achive is to zap
the entire physical machine, which is what the current code does. I am
actually most interested in kdump, though its not working yet. In any
case a flag makes perfect sense. Though it might make sense to add it
when more flexible incarnations of kexec are added.
> > * kexecing into xen does not seem to work, I think that
> > kexec-tools needs updating, but I have not investigated yet
>
> Yep, actually _alot_ of the kexec magic happens in userspace.
Yes, I became aware of that along the way. I'm pretty confident that
the way I have done things, if you fixed up user-space kexec so
that linux -> xen worked, then xen -> xen would also work.
--
Horms
^ permalink raw reply
* Re: RT task scheduling
From: Steven Rostedt @ 2006-04-08 4:45 UTC (permalink / raw)
To: Vernon Mauery
Cc: Bill Huey, Darren Hart, Ingo Molnar, linux-kernel,
Thomas Gleixner, Stultz, John, Peter Williams, Siddha, Suresh B,
Nick Piggin
In-Reply-To: <200604072128.36868.vernux@us.ibm.com>
Hi Vernon,
On Fri, 2006-04-07 at 21:28 -0700, Vernon Mauery wrote:
> 1) Deterministic scheduling algorithms (SWSRPS). Basically, with uniprocessor
> systems (or smp with a global run queue), it was really easy to say, run the
> highest priority task in the queue. But when there are several queues that
> are independent of each other, it is difficult. According to SWSRPS, nr_cpus
> highest priority runnable tasks should _always_ be running (regardless of
> which queue they are on). This might mean that there are longer latencies a)
> to determine the nr_cpus highest priority tasks and b) because of cache
> issues.
Yep, and task cpu dancing. Everytime a High prio task preempts a lower
prio RT task, that RT task might be pushed to another CPU.
>
> 2) Maximum deterministic latency. A task should be able to say that if it
> relinquishes the processor for now, MAX_LATENCY nanoseconds (or ticks or
> whatever you want to measure time in) later, it will be back in time to meet
> a deadline.
Yep, but the more important thing than latency, is to make your
deadline. Sometimes people forget that and just concentrate on latency.
But that's another story.
>
> As I understand it, real time is all about determinism. But there are several
> places where we have to focus on determinism to make it all behave as it
> should.
>
> Priority A > B > C
> If a lower priority task C gets run just because it is the highest in that
> CPU's run queue while there is a higher priority task B is sleeping while A
> runs (on a 2 proc system), this is WRONG.
Argh, terminology is killing us all. For this to be wrong, B isn't
"sleeping" it's "waiting" while in the run state. "Sleeping" means that
it's not on the run queue and is just waiting for some event. Which
would be OK for C to run then. But if B is on the run queue and in the
the TASK_RUNNING state, it would be wrong for C to be running somewhere
where B could be running.
> But then again, we need to make
> sure that we can determine the maximum latency to preempt C to run B and try
> to minimize that.
And here I don't know of another way besides an IPI to preempt C. If C
is in userspace, how would you preempt C right a way if B suddenly wakes
up on the runqueue of A?
>
> Poof! More smoke in the air. I hope that clears it up.
It's as clear as my face was in High School ;)
-- Steve
^ permalink raw reply
* Regarding Wrapfs Code - function wrapfs_interpose
From: UZAIR LAKHANI @ 2006-04-08 4:51 UTC (permalink / raw)
To: linux-fsdevel
Hello All,
I want to find out the purpose of a part of Wrapfs
code.
The function name is wrapfs_interpose
The code is
/* check that the lower file system didn't cross a
mount point */
if (lower_inode->i_sb != SUPERBLOCK_TO_LOWER(sb)) {
err = -EXDEV;
goto out;
}
I want to find out what is the purpose of the above
check.
Thanks,
Uzair Lakhnai
Karachi, Pakistan
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* upgrading from 3.0.1 to 3.0.2
From: rhce admin @ 2006-04-08 4:55 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 675 bytes --]
Hi All,
I've tried upgrading from 3.0.1 to 3.0.2 on a couple of test servers and had
the same strange results on both... In both cases I had a running
3.0.1server, then downloaded the
3.0.2 source. Next, I extracted the files and executed "make
XEN_TARGET_X86_PAE=y world". Upon completion I executed "dist/install.sh",
changed the grub.conf and rebooted. Once the machines rebooted both began
complaining that files in "/etc/rc.d/*" were missing. Various services
failed to start because of this as well as networking.
Does anyone know what may have caused this based on the steps above? Is
there a more preferred way to upgrade from one version to the next?
[-- Attachment #1.2: Type: text/html, Size: 714 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [ALSA - utils 0001990]: aplay/arecord cannot play/capture A_LAW
From: bugtrack @ 2006-04-08 5:47 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1990>
======================================================================
Reported By: Raymond
Assigned To:
======================================================================
Project: ALSA - utils
Issue ID: 1990
Category: aplay/arecord
Reproducibility: always
Severity: major
Priority: normal
Status: new
======================================================================
Date Submitted: 04-01-2006 04:26 CEST
Last Modified: 04-08-2006 07:47 CEST
======================================================================
Summary: aplay/arecord cannot play/capture A_LAW
Description:
aplay/arecord can play MU_LAW and the sound card support MU_LAW and A_LAW
arecord -D hw:0,0 -f MU_LAW -t au -c 1 -r 8000 test.au
aplay -D hw:0,0 test.au
Try to use -t raw but the quality of A_LAW is very bad when compare with
MU_LAW
arecord -D hw:0,0 -f A_LAW -t raw -c 1 -r 8000 test.raw
aplay -D hw:0,0 test.raw
======================================================================
----------------------------------------------------------------------
tiwai - 04-07-06 19:32
----------------------------------------------------------------------
aplay doesn't support A-law in .au format.
----------------------------------------------------------------------
Raymond - 04-08-06 07:47
----------------------------------------------------------------------
cat test.raw > /dev/dsp
or
cat test.raw > /dev/audio
Which of the above will play the sound correctly if test.raw is recorded
by arecord -D hw:0,0 -f A_LAW -t raw -c 1 -r 8000 test.raw ?
Issue History
Date Modified Username Field Change
======================================================================
04-01-06 04:26 Raymond New Issue
04-03-06 07:16 Raymond Note Added: 0009085
04-03-06 07:36 Raymond Note Added: 0009086
04-07-06 19:32 tiwai Note Added: 0009152
04-08-06 07:47 Raymond Note Added: 0009171
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [RFC: 2.6 patch] the overdue removal of RAW1394_REQ_ISO_{LISTEN,SEND}
From: Stefan Richter @ 2006-04-08 5:53 UTC (permalink / raw)
To: Adrian Bunk; +Cc: scjody, linux1394-devel, linux-kernel
In-Reply-To: <20060406224706.GD7118@stusta.de>
Adrian Bunk wrote:
> This patch contains the overdue removal of the RAW1394_REQ_ISO_SEND and
> RAW1394_REQ_ISO_LISTEN request types plus all support code for them.
[...]
I am not familiar with the isochronous part of Linux' 1394 software
stack, so I can't comment whether there are high-profile applications
which still did not migrate away from this interface, or did so only
recently.
However I have a few remarks about this patch:
1. You are not only removing the two ioctls but also two EXPORTs and
their implementations, i.e. hpsb_listen_channel() and
hpsb_make_isopacket().
1.a Nobody scheduled to remove these EXPORTs.
1.b So far we moved unused ieee1394 EXPORTs into #if/#endif blocks
and let people reactivate them via kernel config.
2. If it will be decided to remove or hide the EXPORTs and
implementations, then the following should go as well:
2.a EXPORT and implementation of hpsb_unlisten_channel()
2.b struct member hpsb_host.iso_listen_count[]
3. These should go regardless of the EXPORTs matter:
struct members file_info.listen_channels, file_info.iso_buffer,
file_info.iso_buffer_length.
Perhaps there is even *much* more code which becomes superfluous which I
am unable to identify now.
--
Stefan Richter
-=====-=-==- -=-- -=---
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [Qemu-devel] Translation cache sizes
From: Mulyadi Santosa @ 2006-04-08 6:30 UTC (permalink / raw)
To: qemu-devel, Julian Seward
In-Reply-To: <200604080413.52908.jseward@acm.org>
Hi Julian...
> Using qemu from cvs simulating x86-softmmu (no kqemu) on x86,
> booting SuSE 9.1 and getting to the xdm (kdm?) graphical login
> screen, requires making about 1088000 translations, and the
> translation cache is flushed 17 times. Booting is not too bad,
> but once user-mode starts to run the translation cache is pretty
> much hammered.
Reminds me when I booted FC2 default kernel (4G/4G VM split). Maybe I
suffer the same thing, that is tons of translations and cache flush
inside qemu.
Anyway, mind to share on how did you get the number? Putting such info
on qemu forum (http://qemu.dad-answers.com) will be great too since it
will let/encourage other (casual) user to tweak qemu.
> I made 2 changes:
>
> * increase CODE_GEN_BUFFER_SIZE from 16*1024*1024
> to 64*1024*1024,
I think, if speed is what user really need, he/she won't mind with the
extra 48 MB IMHO. Run qemu in non X environment, use serial output or
curses based display, the extra 48 MB won't hog too much.
> * observe that CODE_GEN_AVG_BLOCK_SIZE of 128
> for the softmmu case is too low; my measurements put it
> at about 247. So I changed it to 256.
so, you double it....that means, there is more than just the extra 48
MB?
> With those changes in place, the same boot-to-kdm process
> requires only about 570000 translations to be made, and 2
> cache flushes to happen. Of course the cost is an extra
> 48M of memory use.
Good to hear! Wow! Maybe we should made those constants configurable
(using ./configure script)?
regards
Mulyadi
^ permalink raw reply
* kernel vs user power management
From: Brown, Len @ 2006-04-08 6:42 UTC (permalink / raw)
To: thoenig, Holger Macht; +Cc: linux-acpi, linux-laptop, Andi Kleen
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.
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.
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.
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.
thanks,
-Len
^ permalink raw reply
* Raid 4 idea!
From: JaniD++ @ 2006-04-08 6:44 UTC (permalink / raw)
To: linux-raid
Hello, list,
I have one idea!
I using raid4, and found to be really good, but i think this can be more
better! :-)
If the raid4 fails one disk (except the patiry disk), the md currently only
drop the disk from array, but i think this could be more useful, if the md
immediately starts to transform the parity disk into the place fo missing
disk!
This is possible, and with this option, performance-dependent systems can go
faster again, after the "rebuild" is completed!
This is only requires one (big) number in superblock to count/track the
process.
Also this has a little risk too, and need to be an "expert" option - i
think...
What do you think, Neil?
Cheers,
Janos
^ permalink raw reply
* Re: Overhead of Using a Stackable File System(Wrapfs)
From: UZAIR LAKHANI @ 2006-04-08 6:48 UTC (permalink / raw)
To: Avishay Traeger; +Cc: linux-fsdevel
In-Reply-To: <1144001272.11270.5.camel@ool-44c32f98.dyn.optonline.net>
--- Avishay Traeger <atraeger@cs.sunysb.edu> wrote:
> On Sun, 2006-04-02 at 01:32 -0800, UZAIR LAKHANI
> wrote:
> > Hello All,
> >
> > I want to enquire about the percent overhead
> involved
> > when we use Wrapfs(null layer stacking file
> system)
> > over ext3.
>
> It should only be a few percent (if I remember
> correctly, less than 5),
> but it would depend on your machine and workload.
> If you want an exact
> answer, just run some benchmarks on ext3 and
> wrapfs/ext3.
>
> > I want to enquire this because I want to use
> Wrapfs in
> > a network environment and there will be an
> additional
> > overhead of network communication.
>
> If you're still talking about implementing NFS using
> stackable file
> systems, please note that we decided that was not a
> good idea.
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.
>
> Good luck.
>
> 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: [PATCH 3/7] uts namespaces: use init_utsname when appropriate
From: Eric W. Biederman @ 2006-04-08 7:09 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: linux-kernel, Kirill Korotaev, herbert, devel, sam, xemul,
James Morris
In-Reply-To: <20060408045206.EAA8E19B8FF@sergelap.hallyn.com>
"Serge E. Hallyn" <serue@us.ibm.com> writes:
> diff --git a/include/asm-i386/elf.h b/include/asm-i386/elf.h
> index 4153d80..8d455e2 100644
> --- a/include/asm-i386/elf.h
> +++ b/include/asm-i386/elf.h
> @@ -108,7 +108,7 @@ typedef struct user_fxsr_struct elf_fpxr
> For the moment, we have only optimizations for the Intel generations,
> but that could change... */
>
> -#define ELF_PLATFORM (system_utsname.machine)
> +#define ELF_PLATFORM (init_utsname()->machine)
>
> #ifdef __KERNEL__
> #define SET_PERSONALITY(ex, ibcs2) do { } while (0)
I think this one needs to be utsname()->machine.
Currently it doesn't matter. But Herbert has expressed
the desire to make a machine appear like an older one.
> diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
> index cb8a92f..81db372 100644
> --- a/net/ipv4/ipconfig.c
> +++ b/net/ipv4/ipconfig.c
> @@ -367,7 +367,7 @@ static int __init ic_defaults(void)
> */
>
> if (!ic_host_name_set)
> - sprintf(system_utsname.nodename, "%u.%u.%u.%u", NIPQUAD(ic_myaddr));
> + sprintf(init_utsname()->nodename, "%u.%u.%u.%u", NIPQUAD(ic_myaddr));
>
> if (root_server_addr == INADDR_NONE)
> root_server_addr = ic_servaddr;
> @@ -806,7 +806,7 @@ static void __init ic_do_bootp_ext(u8 *e
> }
> break;
> case 12: /* Host name */
> - ic_bootp_string(system_utsname.nodename, ext+1, *ext, __NEW_UTS_LEN);
> + ic_bootp_string(init_utsname()->nodename, ext+1, *ext, __NEW_UTS_LEN);
> ic_host_name_set = 1;
> break;
> case 15: /* Domain name (DNS) */
> @@ -817,7 +817,7 @@ static void __init ic_do_bootp_ext(u8 *e
> ic_bootp_string(root_server_path, ext+1, *ext,
> sizeof(root_server_path));
> break;
> case 40: /* NIS Domain name (_not_ DNS) */
> - ic_bootp_string(system_utsname.domainname, ext+1, *ext, __NEW_UTS_LEN);
> + ic_bootp_string(init_utsname()->domainname, ext+1, *ext, __NEW_UTS_LEN);
> break;
> }
> }
> @@ -1369,7 +1369,7 @@ static int __init ip_auto_config(void)
> printk(", mask=%u.%u.%u.%u", NIPQUAD(ic_netmask));
> printk(", gw=%u.%u.%u.%u", NIPQUAD(ic_gateway));
> printk(",\n host=%s, domain=%s, nis-domain=%s",
> - system_utsname.nodename, ic_domain, system_utsname.domainname);
> + init_utsname()->nodename, ic_domain, init_utsname()->domainname);
> printk(",\n bootserver=%u.%u.%u.%u", NIPQUAD(ic_servaddr));
> printk(", rootserver=%u.%u.%u.%u", NIPQUAD(root_server_addr));
> printk(", rootpath=%s", root_server_path);
> @@ -1479,11 +1479,11 @@ static int __init ip_auto_config_setup(c
> case 4:
> if ((dp = strchr(ip, '.'))) {
> *dp++ = '\0';
> - strlcpy(system_utsname.domainname, dp,
> - sizeof(system_utsname.domainname));
> + strlcpy(init_utsname()->domainname, dp,
> + sizeof(init_utsname()->domainname));
> }
> - strlcpy(system_utsname.nodename, ip,
> - sizeof(system_utsname.nodename));
> + strlcpy(init_utsname()->nodename, ip,
> + sizeof(init_utsname()->nodename));
> ic_host_name_set = 1;
> break;
> case 5:
This also probably makes sense as utsname(). It doesn't
really matter as this is before init is executed. But logically
this is a user space or per namespace action.
> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> index aa8965e..97c8439 100644
> --- a/net/sunrpc/clnt.c
> +++ b/net/sunrpc/clnt.c
> @@ -176,10 +176,10 @@ rpc_new_client(struct rpc_xprt *xprt, ch
> }
>
> /* save the nodename */
> - clnt->cl_nodelen = strlen(system_utsname.nodename);
> + clnt->cl_nodelen = strlen(init_utsname()->nodename);
> if (clnt->cl_nodelen > UNX_MAXNODENAME)
> clnt->cl_nodelen = UNX_MAXNODENAME;
> - memcpy(clnt->cl_nodename, system_utsname.nodename, clnt->cl_nodelen);
> + memcpy(clnt->cl_nodename, init_utsname()->nodename, clnt->cl_nodelen);
> return clnt;
>
> out_no_auth:
Using nodename is practically the definition of something
that should per namespace I think. Plus it would be really inconsistent
to use utsname() and the init_utsname for the nfs rpc calls.
Unless I am missing something.
Eric
^ permalink raw reply
* configuration error
From: Gokul K @ 2006-04-08 7:16 UTC (permalink / raw)
To: netfilter-devel
Hi,
I'm trying to install a software called seppl. While
configuring i'm getting the following errors.
checking iptables.h usability... yes
checking iptables.h presence... yes
checking for iptables.h... yes
checking for /lib/iptables... configure: error: ***
Sorry, failed to find iptables plugin directory ***
can anyone tell how to overcome this
thanks
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: RT task scheduling
From: Ingo Molnar @ 2006-04-08 7:16 UTC (permalink / raw)
To: Bill Huey
Cc: Darren Hart, linux-kernel, Thomas Gleixner, Stultz, John,
Peter Williams, Siddha, Suresh B, Nick Piggin
In-Reply-To: <20060407210633.GA15971@gnuppy.monkey.org>
* Bill Huey <billh@gnuppy.monkey.org> wrote:
> On Fri, Apr 07, 2006 at 07:56:20AM -0700, Darren Hart wrote:
> > The rt-overload mechanism is distinct from load balancing. RT overload
> > attempts to make sure the NR_CPUS highest priority runnable tasks are running
> > on each of the available CPUs. This isn't load balancing, this is "system
> > wide strict realtime priority scheduling" (SWSRPS). This scheduling should
> > take place even if there are 1000 non RT tasks on CPU 0 and none on all the
> > others. The load balancer would be responsible for distributing those 1000
> > non rt tasks to all the CPUs.
>
> I'm quite aware of what you're saying as well as a much of the
> contents of the -rt patch. Please don't assume that I'm not aware of
> this. The -rt patch doesn't do SWSRPS, [...]
to the contrary, the "RT overload" code in the -rt tree does strict,
system-wide RT priority scheduling. That's the whole point of it.
Ingo
^ permalink raw reply
* Re: RT task scheduling
From: Ingo Molnar @ 2006-04-08 7:25 UTC (permalink / raw)
To: Bill Huey
Cc: Darren Hart, linux-kernel, Thomas Gleixner, Stultz, John,
Peter Williams, Siddha, Suresh B, Nick Piggin
In-Reply-To: <20060408071657.GA11660@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> * Bill Huey <billh@gnuppy.monkey.org> wrote:
>
> > I'm quite aware of what you're saying as well as a much of the
> > contents of the -rt patch. Please don't assume that I'm not aware of
> > this. The -rt patch doesn't do SWSRPS, [...]
>
> to the contrary, the "RT overload" code in the -rt tree does strict,
> system-wide RT priority scheduling. That's the whole point of it.
so after this "clarification of terminology" i hope you are in picture
now, so could you please explain to me what you meant by:
> > You should consider for a moment to allow for the binding of a
> > thread to a CPU to determine the behavior of a SCHED_FIFO class task
> > instead of creating a new run category. [...]
to me it still makes no sense, and much of the followups were based on
this. Or were you simply confused about what the scheduling code in -rt
does precisely? Did that get clarified now?
Ingo
^ permalink raw reply
* Re: [RFC] Hypercalls from HVM guests
From: Keir Fraser @ 2006-04-08 7:31 UTC (permalink / raw)
To: Steve Ofsthun; +Cc: xen-devel
In-Reply-To: <4436BDE2.5090504@virtualiron.com>
On 7 Apr 2006, at 20:30, Steve Ofsthun wrote:
>> Actually, maybe using an unused index for CPUID (e.g. 0xb0000000)
>> would
>> be better? As that's defined to return all zero's, and not cause any
>> traps whatever value you use (unless the CPU is so old that it doesn't
>> support CPUID, of course).
>
> This sounds encouraging, but is CPUID always trapped by the HVM code?
It can be, and in practise yes it is so this could work.
-- Keir
^ 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.