* [ALSA - utils 0001990]: aplay/arecord cannot play/capture A_LAW
From: bugtrack @ 2006-04-25 9:46 UTC (permalink / raw)
To: alsa-devel
The following issue has been RESOLVED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1990>
======================================================================
Reported By: Raymond
Assigned To: tiwai
======================================================================
Project: ALSA - utils
Issue ID: 1990
Category: aplay/arecord
Reproducibility: always
Severity: major
Priority: normal
Status: resolved
Resolution: not an issue
Fixed in Version:
======================================================================
Date Submitted: 04-01-2006 04:26 CEST
Last Modified: 04-25-2006 11:46 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
======================================================================
----------------------------------------------------------------------
Raymond - 04-25-06 02:59
----------------------------------------------------------------------
au88xx driver also support A-Law and MU-LAW.
aplay -v -f A_LAW -Dossdriver test.raw
Playing raw data 'test.raw' : A-Law, Rate 8000 Hz, Mono
aplay: set_params:901: Sample format non available
pcm.alawoss {
type alaw
slave {
pcm ossdriver
format S16_LE
}
}
aplay -v -f A_LAW -Dalawoss test.raw
Playing raw data 'test.raw' : A-Law, Rate 8000 Hz, Mono
A-Law conversion PCM (S16_LE)
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : A_LAW
subformat : STD
channels : 1
rate : 8000
exact rate : 8000 (8000/1)
msbits : 8
buffer_size : 4096
period_size : 1024
period_time : 128000
tick_time : 0
tstamp_mode : NONE
period_step : 1
sleep_min : 0
avail_min : 1024
xfer_align : 1024
start_threshold : 4096
stop_threshold : 4096
silence_threshold: 0
silence_size : 0
boundary : 1073741824
Slave: ALSA <-> OSS PCM I/O Plugin
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 8000
exact rate : 8000 (8000/1)
msbits : 16
buffer_size : 4096
period_size : 1024
period_time : 128000
tick_time : 0
tstamp_mode : NONE
period_step : 1
sleep_min : 0
avail_min : 1024
xfer_align : 1024
start_threshold : 4096
stop_threshold : 4096
silence_threshold: 0
silence_size : 0
boundary : 1073741824
----------------------------------------------------------------------
tiwai - 04-25-06 11:46
----------------------------------------------------------------------
IT IS OFF-TOPIC.
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
04-10-06 16:52 tiwai Note Added: 0009199
04-11-06 07:46 Raymond Note Added: 0009229
04-11-06 07:55 Raymond Note Edited: 0009229
04-11-06 09:41 Raymond Note Edited: 0009229
04-20-06 15:29 tiwai Status new => resolved
04-20-06 15:29 tiwai Resolution open => not an issue
04-20-06 15:29 tiwai Assigned To => tiwai
04-20-06 15:29 tiwai Note Added: 0009384
04-24-06 15:07 Raymond Status resolved => feedback
04-24-06 15:07 Raymond Resolution not an issue => reopened
04-24-06 15:07 Raymond Note Added: 0009451
04-24-06 15:48 tiwai Status feedback => resolved
04-24-06 15:48 tiwai Resolution reopened => not an issue
04-24-06 15:48 tiwai Note Added: 0009453
04-24-06 16:43 Raymond Status resolved => feedback
04-24-06 16:43 Raymond Resolution not an issue => reopened
04-24-06 16:43 Raymond Note Added: 0009468
04-24-06 16:50 tiwai Status feedback => resolved
04-24-06 16:50 tiwai Resolution reopened => not an issue
04-24-06 16:50 tiwai Note Added: 0009472
04-25-06 02:59 Raymond Status resolved => feedback
04-25-06 02:59 Raymond Resolution not an issue => reopened
04-25-06 02:59 Raymond Note Added: 0009483
04-25-06 11:46 Raymond File Added: pcm_oss_mulaw_alaw.patch
04-25-06 11:46 tiwai Status feedback => resolved
04-25-06 11:46 tiwai Resolution reopened => not an issue
04-25-06 11:46 tiwai Note Added: 0009487
======================================================================
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* Re: Use case NetFilter
From: Rob Sterenborg @ 2006-04-25 9:42 UTC (permalink / raw)
To: netfilter
In-Reply-To: <64B84B6DA4DD894EB9D0ABA9F1C1F14EF7FEFF@PUEXCBJ0.nanterre.franceteleco m.fr>
On Tue, April 25, 2006 10:45, THIEBAUD Christophe ROSI/DPS wrote:
> Hi,
>
> I have a question about NetFilter using.
>
> Here a part of my configuration :
> ...
> iptables -A INPUT -m state --state NEW -j LOG --log-prefix "NEW SSH : "
Your logging rule is wrong. This is not NEW SSH. This is NEW SSH:
$ipt -A INPUT -m state --state NEW -p tcp --dport 22 \
-j LOG --log-prefix "NEW SSH : "
> iptables -A INPUT -m state --state ESTABLISHED -j LOG --log-prefix
> "ESTABLISHED SSH : "
This rule is not ESTABLISHED SSH. Add "-p tcp --dport 22" to the rule.
> iptables -A INPUT -d $IPADDR_ADMIN -p tcp --dport 22 -m state --state
> NEW,ESTABLISHED -j ACCEPT
What is $IPADDR_ADMIN ?
> iptables -A OUTPUT -s $IPADDR_ADMIN -p tcp --sport
> 22 -m state --state ESTABLISHED -j ACCEPT ...
What is $IPADDR_ADMIN ?
IF $IPADDR_ADMIN is the IP address of your admin workstation, you have
reversed the -d and -s parameters in both rules above.
> When I send this kind of packet (avec Ftester tools) :
>
> 1 - 10.170.225.0:1025 > 10.64.19.212:22 AP TCP 0
>
> I have this trace :
>
> Apr 25 09:46:39 unzs148 kernel: NEW SSH input : IN=eth0 OUT=
> MAC=00:0d:60:9a:30:9a:00:0d:60:d5:1a:f0:08:00 SRC=10.170.225.0
> DST=10.64.19.212 LEN=55 TOS=0x00 PREC=0x00 TTL=200 ID=1 DF PROTO=TCP SPT=1025
> DPT=22 WINDOW=65535 RES=0x00 ACK PSH URGP=0
>
> And the packet have passed the FW !!!
>
> The FW see the packet as a "new connection" (state NEW), and I have never
> send packek with SYN flag !!!
Your logging will give a false result because it logs MUCH more than (I think)
you want to.
And, again, if my presumption is correct, I think you have reversed -d and -s
in the INPUT and OUTPUT chain. In the INPUT chain, you want to accept with
*source ip* (-s) and in the OUTPUT chain, you want to accept with *destination
ip* (-d).
Gr,
Rob
^ permalink raw reply
* Question about porting linux2.6 on mpc860T
From: bharathi kandimalla @ 2006-04-25 9:29 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org; +Cc: linuxppc-embedded@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 464 bytes --]
Hi
I know there exits a lot of changes in the linux2.6
and i want to know what are the changes
related to architecture?
As mpc860T is a slow processor
Is it considerably slow for mpc860T on linux 2.6 ?
I came to know there are some bugs on mpc860T for linux2.6
Is there any bugs?
what version of linux(2.4/2.6) is good for mpc860T ?
regards
thank you.
---------------------------------
Yahoo! Mail goes everywhere you do. Get it on your phone.
[-- Attachment #2: Type: text/html, Size: 682 bytes --]
^ permalink raw reply
* Re: Avoid printing pointless tsc skew msgs.
From: Andi Kleen @ 2006-04-25 9:35 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel
In-Reply-To: <20060424215239.GA1178@redhat.com>
Dave Jones <davej@redhat.com> writes:
> These messages are kinda silly..
>
> CPU#0 had 0 usecs TSC skew, fixed it up.
> CPU#1 had 0 usecs TSC skew, fixed it up.
>
> inspired from: http://bugzilla.kernel.org/attachment.cgi?id=7713&action=view
Actually it's not correct because if you fixed it up it won't be 0 usecs
again because of the error it adds
(I'm actually not sure how it even managed to measure 0 usecs)
-Andi
^ permalink raw reply
* Re: [PATCH 4 of 13] ipath - change handling of PIO buffers
From: Segher Boessenkool @ 2006-04-25 9:32 UTC (permalink / raw)
To: Bryan O'Sullivan; +Cc: rdreier, openib-general, linux-kernel
In-Reply-To: <8e724d49e74bc1155f4e.1145913780@eng-12.pathscale.com>
> + * The problem with this is that it's global, but we'll use different
> + * numbers for different chip types. So the default value is not
> + * very useful. I've redefined it for the 1.3 release so that it's
----------------------------------------------^^^
Change this to 2.6.17?
> + * zero unless set by the user to something else, in which case we
> + * try to respect it.
Segher
^ permalink raw reply
* Re: RE: [Xen-tools] xen doesn't support "Framebuffer consolesupport"properly
From: Mathieu Ropert @ 2006-04-25 9:31 UTC (permalink / raw)
To: Robert Mortimer; +Cc: xen-tools, Andrew Liu, xen-devel
In-Reply-To: <000c01c667af$05f974d0$5f00000a@rmortimer>
Basically, *any* screen output require access to video memory :)
However, Xen offer a virtual console facility to domU so they can output
things, but it's a text-only console (although they are some projects of
providing a virtual framebuffer support).
Dom0 has direct access to video memory so it shouldn't be a problem to
use framebuffer on it.
Mathieu
Robert Mortimer wrote:
>Is this a DomU or a Dom0 kernel?
>
>>From my scant understanding the following is true:-
>
>only Dom0 gets to see the true hardware still runs above the hypervisor
>
>If frambuffer mode requires direct access to hardware then it may not work.
>I am not positive but does frambuffer involves direct writing to video
>memory
>
>DomU gets to see idealized Xen hardware and presumably uses some sort of Xen
>video driver.
>
>DomU does no direct rendering to screen instead it uses VNC
>
>I may however be so so wrong as I am a bit new to this
>
>Robert
>
>
>
>>-----Original Message-----
>>
>>When I turn on the "Framebuffer console support" in compiling kernel,
>>after system startup, the console doesn't work properly and the kernel
>>parameter( for example: vga=719) doesn't do any effect on kernel.
>>
>>who can help me ?
>>thanks in advance!
>>Andrew Liu
>>
>>
>>
>>_______________________________________________
>>Xen-tools mailing list
>>Xen-tools@lists.xensource.com
>>http://lists.xensource.com/xen-tools
>>
>>
>>
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>
^ permalink raw reply
* Re: tip for MOTU MIDI users - 64bit lockups workaround/fix
From: Matthias Koenig @ 2006-04-25 9:27 UTC (permalink / raw)
To: Allan Klinbail; +Cc: alsa-user, Alsa-dev
In-Reply-To: <1145953559.9892.7.camel@daw.littlewolf>
Allan Klinbail <allan_k@dodo.com.au> writes:
> I don't know why this works but I thought I better share it.
> Up until today I haven't been able to get my MOTU MTP-AV to work
> correctly in 64-bit linux. The entire PC would lock up as soon as it was
> accessed... .
Is this the mtpav driver?
Maybe this should be filed as bug report?
> In the driver options instead of pointing it to IRQ 5, as that is how my
> motherboard is set, I pointed it to IRQ 3.This was done out of confusion
> between DMA and IRQ number, not deliberately. Ironically, it now works.
>
> I haven't completely tested the timing but the MIDI messages are being
> sent to the right port at what seems to be the right time..
Transmitting MIDI likely does not depend on interrupts.
The question is if you can receive MIDI messages from external devices?
Regards,
Matthias
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* Re: [PATCH 02/02] Process Events - License Change
From: Matt Helsley @ 2006-04-25 9:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML, Guillaume Thouvenin, Nguyen Anh Quynh
In-Reply-To: <1145956109.28976.133.camel@stark>
Change the license on the process event structure passed between kernel and
userspace.
Signed-off-by: Matt Helsley <matthltc@us.ibm.com>
--
Index: linux-2.6.17-rc2/include/linux/cn_proc.h
===================================================================
--- linux-2.6.17-rc2.orig/include/linux/cn_proc.h
+++ linux-2.6.17-rc2/include/linux/cn_proc.h
@@ -1,27 +1,20 @@
/*
* cn_proc.h - process events connector
*
* Copyright (C) Matt Helsley, IBM Corp. 2005
* Based on cn_fork.h by Nguyen Anh Quynh and Guillaume Thouvenin
- * Original copyright notice follows:
* Copyright (C) 2005 Nguyen Anh Quynh <aquynh@gmail.com>
* Copyright (C) 2005 Guillaume Thouvenin <guillaume.thouvenin@bull.net>
*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2.1 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/
#ifndef CN_PROC_H
#define CN_PROC_H
^ permalink raw reply
* Re: [PATCH 01/02] Process Events - Header Cleanup
From: Matt Helsley @ 2006-04-25 9:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML, Guillaume Thouvenin, Nguyen Anh Quynh
In-Reply-To: <1145956109.28976.133.camel@stark>
Move connector header include to precisely where it's needed.
Remove unused time.h header file as well. This was leftover from previous iterations
of the process events patches.
Compiles on x86. Tested on ppc64.
Please apply to -mm.
Signed-off-by: Matt Helsley <matthltc@us.ibm.com>
--
Index: linux-2.6.17-rc2/drivers/connector/cn_proc.c
===================================================================
--- linux-2.6.17-rc2.orig/drivers/connector/cn_proc.c
+++ linux-2.6.17-rc2/drivers/connector/cn_proc.c
@@ -24,10 +24,11 @@
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/ktime.h>
#include <linux/init.h>
+#include <linux/connector.h>
#include <asm/atomic.h>
#include <linux/cn_proc.h>
#define CN_PROC_MSG_SIZE (sizeof(struct cn_msg) + sizeof(struct proc_event))
Index: linux-2.6.17-rc2/include/linux/cn_proc.h
===================================================================
--- linux-2.6.17-rc2.orig/include/linux/cn_proc.h
+++ linux-2.6.17-rc2/include/linux/cn_proc.h
@@ -24,12 +24,10 @@
#ifndef CN_PROC_H
#define CN_PROC_H
#include <linux/types.h>
-#include <linux/time.h>
-#include <linux/connector.h>
/*
* Userspace sends this enum to register with the kernel that it is listening
* for events on the connector.
*/
^ permalink raw reply
* Re: C++ pushback
From: Xavier Bestel @ 2006-04-25 9:22 UTC (permalink / raw)
To: Avi Kivity; +Cc: Martin Mares, J.A. Magallon, Alan Cox, Linux-Kernel,
In-Reply-To: <444DE829.2000101@argo.co.il>
On Tue, 2006-04-25 at 11:13, Avi Kivity wrote:
> Martin Mares wrote:
> >>> Calling a C function is simple and explicit -- a quick glance over
> >>> the code is enough to tell what gets called.
> >>>
> >>>
> >> No, you need to check all the functions it calls as well.
> >>
> >
> > Yes, but if it calls none (or calls basic functions I already know),
> > it's immediately visible without having to circumnavigate the globe
> > to find declarations of all sub-objects :)
> >
> >
> Yes, but if the constructor constructs no sub objects (or basic objects
> you already know) then it's immediately visible as well.
Yes, "if". With straight C, it's immediatly obvious the kmalloc() is the
only function with side-effects and special requirements - an
experienced hacker won't even look it up. With C++ those may be hidden
behind each object or object member, that's the philosophy of the
language.
The problem is that in kernel mode you must know precisely when and how
you allocate memory.
Xav
^ permalink raw reply
* [PATCH 00/02] Process Events - Header Cleanup and License Change
From: Matt Helsley @ 2006-04-25 9:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML, Guillaume Thouvenin, Nguyen Anh Quynh
Andrew,
This series of patches cleans up the Process Events header in
include/linux/cn_proc.h in the first patch and then changes the license
of cn_proc.h to LGPL in the second patch. As copyright holders to the
work the header was derived from (mentioned at the top of the header) I
think Guillaume Thouvenin and Nguyen Anh Quynh should sign-off or [n]ack
the second patch before it can go in.
Please consider applying these to -mm.
Thanks,
-Matt Helsley <matthltc@us.ibm.com>
^ permalink raw reply
* FIXED Re: [PATCH] remove likely in ip_rcv_finish()
From: Hua Zhong @ 2006-04-25 9:20 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <Pine.LNX.4.64.0604250204470.4481@localhost.localdomain>
Horrible typo! I really should have gone to sleep now.
Correct patch attached.
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 18d7fad..c9026db 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -337,7 +337,7 @@ static inline int ip_rcv_finish(struct s
* Initialise the virtual path cache for the packet. It describes
* how the packet travels inside Linux networking.
*/
- if (likely(skb->dst == NULL)) {
+ if (skb->dst == NULL) {
int err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos,
skb->dev);
if (unlikely(err)) {
^ permalink raw reply related
* Re: Reduce the size of a probed flash for broken HW
From: Franck Bui-Huu @ 2006-04-25 9:19 UTC (permalink / raw)
To: linux-mtd; +Cc: Franck, Nicolas Pitre
In-Reply-To: <cda58cb80604240740j62e51ecctb3ad75673b98445a@mail.gmail.com>
2006/4/24, Franck Bui-Huu <vagabon.xyz@gmail.com>:
> [discussed with Vitaly Wool on IRC]
>
> My hardware has some problem to access my onboard flashes specially
> the last 64Ko of them. So I need a way to restrict access to these areas.
>
> Several solutions comes in mind:
>
> - In the mapping driver, try to modify the mtd_info and cfi_info
> setup by the MTD probing functions to reduce the detected
> size. This solution is really hackish since it modifies internal
> structures of the MTD layer that the mapping driver is not
> supposed to be aware of. I just did this in my driver:
>
> *mtd = do_map_probe("xxx_probe", map);
> while ((*mtd)->size > 32Mo - 64Ko)
> (*mtd)->size -= (*mtd)->erasesize;
>
> and it seems to work fine...
>
> - Use a partition that exclude the last 64Ko of the flash. This
> solution was suggested by Nicolas Pitre, but I think it imposes
> some restrictions on flash concatenation for example.
>
in case someone is interested, here is the implementation of the first
and second solutions:
static struct mtd_info * __init fix_mtd_size(struct mtd_info *mtd)
{
#if 0
while (mtd->size > MAX_BANK_SIZE)
mtd->size -= mtd->erasesize;
return mtd;
#else
struct mtd_partition fixed_part;
struct mtd_info *fixed_mtd = NULL;
memset(&fixed_part, 0, sizeof (struct mtd_partition));
fixed_part.name = mtd->name;
fixed_part.size = mtd->size;
while (fixed_part.size > MAX_BANK_SIZE)
fixed_part.size -= mtd->erasesize;
fixed_part.mtdp = &fixed_mtd;
add_mtd_partitions(mtd, &fixed_part, 1);
return fixed_mtd;
#endif
}
--
Franck
^ permalink raw reply
* Re: [PATCH] Profile likely/unlikely macros
From: Andreas Mohr @ 2006-04-25 9:19 UTC (permalink / raw)
To: Daniel Walker; +Cc: linux-kernel, akpm, hzhong
In-Reply-To: <200604250257.k3P2vlEb012502@dwalker1.mvista.com>
Hi,
On Mon, Apr 24, 2006 at 07:57:47PM -0700, Daniel Walker wrote:
> This patch adds a very lightweight profiling feature to the
> likely/unlikely macros. It should work in all contexts including
> NMI, and during boot. The patch is for 2.6.17-rc2 .
Wow, very nice! I had actually had that idea myself, so it's nice to see
it already implemented, and with very nice output.
Rest assured that I'll do my fair share of testing with it!
Thanks a lot!
Andreas Mohr
^ permalink raw reply
* Re: [PATCH 05/16] GFS2: File and inode operations
From: Steven Whitehouse @ 2006-04-25 9:27 UTC (permalink / raw)
To: Andreas Dilger; +Cc: Andrew Morton, linux-fsdevel, linux-kernel
In-Reply-To: <20060424221957.GW6075@schatzie.adilger.int>
Hi,
On Mon, 2006-04-24 at 16:19 -0600, Andreas Dilger wrote:
> On Apr 24, 2006 14:53 +0100, Steven Whitehouse wrote:
> > On Sun, 2006-04-23 at 01:55 -0600, Andreas Dilger wrote:
> > > > +++ b/include/linux/iflags.h
> > > > @@ -0,0 +1,104 @@
> > > > +#define IFLAG_TOPDIR __IFL(TopDir) /* 0x00020000 */
> > > > +#define IFLAG_DIRECTIO __IFL(DirectIO) /* 0x00040000 */
> > > > +#define IFLAG_INHERITDIRECTIO __IFL(InheritDirectIO) /* 0x00080000 */
> > > > +#define IFLAG_INHERITJDATA __IFL(InheritJdata) /* 0x00100000 */
> > > > +#define IFLAG_RESERVED __IFL(Reserved) /* 0x80000000 */
> > >
> > > Actually, the 0x0080000 flag has been reserved by e2fsprogs for ext3
> > > extents for a while already. AFAICS, there are no other flags in the
> > > current e2fsprogs that aren't listed above.
> >
> > So if I call that one IFLAG_EXTENT, then I presume that will be ok?
> > What about the 0x00040000 flag? That would seem to be a gap in the
> > sequence (ignoring GFS flags for now), so should I leave that reserved
> > for use by ext2/3 as well?
>
> To be honest, I don't know if 0x40000 is used or not. It isn't in the
> e2fsprogs version of ext2_fs.h.
>
Hmmm... I think I might leave it "spare" all the same just in case
something else is using it. We can always fill it in later if thats not
the case.
> > > The other tidbit is that new ext2/ext3 files generally inherit the flags
> > > from their parent directory, so it isn't clear if there is really a need
> > > for a distinction between DIRECTIO and INHERIT_DIRECTIO, and similarly
> > > JDATA and INHERIT_JDATA? Generally, I'd think that JDATA isn't meaningful
> > > on directories (since they are metadata and journaled anyways), nor is
> > > DIRECTIO so their only meaning on a directory is "INHERIT for new files".
> >
> > Yes, that sounds like a good plan. The only downside (purely from a GFS2
> > point of view, it won't affect anybody else) means that its no longer a
> > 1:1 relationship between flags, so in order to do the conversion, I'd
> > have to use something a little more elaborate than the inline function I
> > added to the iflags.h header file,
>
> Hmm, maybe I don't understand the GFS2 issue then? Why not just use
> IFLAG_JDATA on the directory and remove the use of IFLAG_INHERITJDATA
> (equivalent) entirely from GFS2? Does the implementation depend on a
> distinction between these on a directory?
>
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Software Engineer
> Cluster File Systems, Inc.
>
Its just a question of being compatible with GFS1 so far as the on disk
format goes. The gfs2_dinode structure is 100% backward compatible
(there are a couple of fields used in GFS1 no longer used in GFS2, but
they are otherwise identical) and this includes the flags. If I were
designing from scratch I'd certainly have merged the flags into one as
you suggest. Its not a big problem though - I just need to add a bit of
extra conversion code. Its better to do that than clutter the user
interface with redundant flags I think, especially when there are a
limited number,
Steve.
^ permalink raw reply
* Re: [PATCH] pciback: deferred handling of pci configuration space accesses
From: Keir Fraser @ 2006-04-25 9:17 UTC (permalink / raw)
To: Keir Fraser; +Cc: Ryan, xen-devel
In-Reply-To: <70f0bc8ca96a3633374ecc6863bb2fd6@cl.cam.ac.uk>
On 25 Apr 2006, at 09:15, Keir Fraser wrote:
>> Previously, the virtual configuration space handlers ran in
>> the same context as the event channel interrupt handler (which was
>> often
>> atomic if not always atomic). Now the interrupt handler schedules a
>> callback function (a bottom half) in the system work queue (keventd)
>> that will get called in process context at a slightly later time. This
>> allows the handlers in the virtual configuration space to run in
>> process
>> context and to call any core PCI function regardless of whether it
>> will
>> sleep or not.
>
> This is okay in principle, but I found the op_in_progress counter
> rather confusing and I'm not sure why it's needed? If it's to prevent
> a double schedule_work() call on a single PCI request then I'm not
> sure that it's watertight. Does it need to be?
Let me be a bit more specific here: I think that if an interrupt is
delivered after the work function has incremented op_in_progress, but
before it clears _PCIF_active, then work can be scheduled erroneously
because the IRQ handler will see atomic_dec_and_test() return TRUE.
If serialised execution of pci requests is important, and it looks like
it is, I think the simplest solution is simply to create your own
single-threaded workqueue and queue_work() onto that. Personally I get
worried about using the shared workqueues anyway, as they're another
shared resource to deadlock on.
-- Keir
^ permalink raw reply
* Re: [PATCH] Profile likely/unlikely macros
From: Mikael Pettersson @ 2006-04-25 9:15 UTC (permalink / raw)
To: dwalker, linux-kernel; +Cc: akpm, hzhong
On Mon, 24 Apr 2006 19:57:47 -0700, Daniel Walker wrote:
>+ if (likeliness->type & LIKELY_UNSEEN) {
>+ if (atomic_dec_and_test(&likely_lock)) {
>+ if (likeliness->type & LIKELY_UNSEEN) {
>+ likeliness->type &= (~LIKELY_UNSEEN);
>+ likeliness->next = likeliness_head;
>+ likeliness_head = likeliness;
>+ }
>+ }
>+ atomic_inc(&likely_lock);
>+ }
I'm pretty sure one can do this (prepending an element to a list)
w/o fiddling with locks by using CAS and looping until successful.
/Mikael
^ permalink raw reply
* Re: C++ pushback
From: Nikita Danilov @ 2006-04-25 9:09 UTC (permalink / raw)
To: J.A. Magallon; +Cc: Linux Kernel Mailing List
In-Reply-To: <20060425001617.0a536488@werewolf.auna.net>
J.A. Magallon writes:
[...]
>
> Tell me what is the difference between:
>
>
> sbi = kmalloc(sizeof(*sbi), GFP_KERNEL);
> if (!sbi)
> return -ENOMEM;
> sb->s_fs_info = sbi;
> memset(sbi, 0, sizeof(*sbi));
> sbi->s_mount_opt = 0;
> sbi->s_resuid = EXT3_DEF_RESUID;
> sbi->s_resgid = EXT3_DEF_RESGID;
>
> and
>
> SuperBlock() : s_mount_opt(0), s_resuid(EXT3_DEF_RESUID), s_resgid(EXT3_DEF_RESGID)
> {}
>
> ...
> sbi = new SuperBlock;
> if (!sbi)
> return -ENOMEM;
>
> apart that you don't get members initalized twice and get a shorter code :).
The difference is that second fragment doesn't mention GFP_KERNEL, so
it's most likely wrong. Moreover it's shorter only because it places
multiple initializations on the same like, hence, contradicting
CodingStyle.
>
> --
> J.A. Magallon <jamagallon()able!es> \ Software is like sex:
Nikita.
^ permalink raw reply
* Re: C++ pushback
From: Avi Kivity @ 2006-04-25 9:13 UTC (permalink / raw)
To: Martin Mares; +Cc: Xavier Bestel, J.A. Magallon, Alan Cox, Linux-Kernel,
In-Reply-To: <mj+md-20060425.090134.27024.atrey@ucw.cz>
Martin Mares wrote:
>>> Calling a C function is simple and explicit -- a quick glance over
>>> the code is enough to tell what gets called.
>>>
>>>
>> No, you need to check all the functions it calls as well.
>>
>
> Yes, but if it calls none (or calls basic functions I already know),
> it's immediately visible without having to circumnavigate the globe
> to find declarations of all sub-objects :)
>
>
Yes, but if the constructor constructs no sub objects (or basic objects
you already know) then it's immediately visible as well.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: C++ pushback
From: Harald Arnesen @ 2006-04-25 9:12 UTC (permalink / raw)
To: Diego Calleja; +Cc: jamagallon, alan, linux-kernel
In-Reply-To: <20060425024625.288f616e.diegocg@gmail.com>
Diego Calleja <diegocg@gmail.com> writes:
> El Tue, 25 Apr 2006 02:05:29 +0200,
> Harald Arnesen <harald@skogtun.org> escribió:
>
>> The former is easier to read and understand?
>
> C is not perfect, it could very well get a bit improved so it helps to make
> the code more readable, etc (and I mean: just improvements, not "lets try to
> turn C into a OO language"). That however requires modifying the current
> C standards, gcc...
>
> But that doesn't justifies adding C++ support to the kernel.
It was the C version I found easier to understand.
--
Hilsen Harald.
^ permalink raw reply
* [PATCH] remove likely in ip_rcv_finish()
From: Hua Zhong @ 2006-04-25 9:10 UTC (permalink / raw)
To: davem, netdev
Hi,
This is another result from my likely profiling tool (dwalker@mvista.com just sent the patch of the profiling tool to linux-kernel mailing list, which is similar to what I use).
On my system (not very busy, normal development machine within a VMWare workstation), I see a 6/5 miss/hit ratio for the following "likely".
I am not sure what would happen for a busy system though (on which performance actually matters), but I am just reporting what I find and hope it might help.
Signed-off-by: Hua Zhong <hzhong@gmail.com>
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 18d7fad..9f44359 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -337,7 +337,7 @@ static inline int ip_rcv_finish(struct s
* Initialise the virtual path cache for the packet. It describes
* how the packet travels inside Linux networking.
*/
- if (likely(skb->dst == NULL)) {
+ if (skb->dst) {
int err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos,
skb->dev);
if (unlikely(err)) {
^ permalink raw reply related
* [PATCH 2/2] ipmi: strstrip conversion
From: Pekka Enberg @ 2006-04-25 9:11 UTC (permalink / raw)
To: akpm; +Cc: minyard, linux-kernel
From: Pekka Enberg <penberg@cs.helsinki.fi>
This patch switches an open-coded strstrip to use the new API.
Cc: Corey Minyard <minyard@acm.org>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
drivers/char/ipmi/ipmi_watchdog.c | 25 +++++++++----------------
1 files changed, 9 insertions(+), 16 deletions(-)
342eaae5800b0fd002f5101d66ccb02e786016d8
diff --git a/drivers/char/ipmi/ipmi_watchdog.c b/drivers/char/ipmi/ipmi_watchdog.c
index 2d11ddd..8f88671 100644
--- a/drivers/char/ipmi/ipmi_watchdog.c
+++ b/drivers/char/ipmi/ipmi_watchdog.c
@@ -212,24 +212,16 @@ static int set_param_str(const char *val
{
action_fn fn = (action_fn) kp->arg;
int rv = 0;
- const char *end;
- char valcp[16];
- int len;
-
- /* Truncate leading and trailing spaces. */
- while (isspace(*val))
- val++;
- end = val + strlen(val) - 1;
- while ((end >= val) && isspace(*end))
- end--;
- len = end - val + 1;
- if (len > sizeof(valcp) - 1)
- return -EINVAL;
- memcpy(valcp, val, len);
- valcp[len] = '\0';
+ char *dup, *s;
+
+ dup = kstrdup(val, GFP_KERNEL);
+ if (!dup)
+ return -ENOMEM;
+
+ s = strstrip(dup);
down_read(®ister_sem);
- rv = fn(valcp, NULL);
+ rv = fn(s, NULL);
if (rv)
goto out_unlock;
@@ -239,6 +231,7 @@ static int set_param_str(const char *val
out_unlock:
up_read(®ister_sem);
+ kfree(dup);
return rv;
}
--
1.3.0
^ permalink raw reply related
* [PATCH] update xen caps on x86_64 since we have hvm pae guests support now
From: Li, Xin B @ 2006-04-25 9:11 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
update xen caps on x86_64 since we have hvm pae guests support now
Signed-off-by: Xin Li <xin.b.li@intel.com>
[-- Attachment #2: xen_caps.patch --]
[-- Type: application/octet-stream, Size: 567 bytes --]
diff -r a5fcffc826f3 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c Mon Apr 24 18:07:27 2006 +0100
+++ b/xen/arch/x86/setup.c Tue Apr 25 17:06:32 2006 +0800
@@ -634,7 +634,7 @@ void arch_get_xen_caps(xen_capabilities_
if ( hvm_enabled )
{
p += sprintf(p, "hvm-%d.%d-x86_32 ", XEN_VERSION, XEN_SUBVERSION);
- //p += sprintf(p, "hvm-%d.%d-x86_32p ", XEN_VERSION, XEN_SUBVERSION);
+ p += sprintf(p, "hvm-%d.%d-x86_32p ", XEN_VERSION, XEN_SUBVERSION);
p += sprintf(p, "hvm-%d.%d-x86_64 ", XEN_VERSION, XEN_SUBVERSION);
}
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [PATCH 1/2] strstrip API
From: Pekka Enberg @ 2006-04-25 9:11 UTC (permalink / raw)
To: akpm; +Cc: holzheu, ioe-lkml, joern, minyard, linux-kernel
From: Pekka Enberg <penberg@cs.helsinki.fi>
This patch adds a new strstrip() function to lib/string.c for removing
leading and trailing whitespace from a string.
Cc: Michael Holzheu <holzheu@de.ibm.com>
Cc: Ingo Oeser <ioe-lkml@rameria.de>
Cc: Jörn Engel <joern@wohnheim.fh-wedel.de>
Cc: Corey Minyard <minyard@acm.org>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
include/linux/string.h | 1 +
lib/string.c | 30 ++++++++++++++++++++++++++++++
2 files changed, 31 insertions(+), 0 deletions(-)
1a360da62131fb81460ca4abf93d20b9d0d390ff
diff --git a/include/linux/string.h b/include/linux/string.h
index c61306d..e4c7558 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -56,6 +56,7 @@ #endif
#ifndef __HAVE_ARCH_STRRCHR
extern char * strrchr(const char *,int);
#endif
+extern char * strstrip(char *);
#ifndef __HAVE_ARCH_STRSTR
extern char * strstr(const char *,const char *);
#endif
diff --git a/lib/string.c b/lib/string.c
index 064f631..6307726 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -301,6 +301,36 @@ char *strnchr(const char *s, size_t coun
EXPORT_SYMBOL(strnchr);
#endif
+/**
+ * strstrip - Removes leading and trailing whitespace from @s.
+ * @s: The string to be stripped.
+ *
+ * Note that the first trailing whitespace is replaced with a %NUL-terminator
+ * in the given string @s. Returns a pointer to the first non-whitespace
+ * character in @s.
+ */
+char *strstrip(char *s)
+{
+ size_t size;
+ char *end;
+
+ size = strlen(s);
+
+ if (!size)
+ return s;
+
+ end = s + size - 1;
+ while (end != s && isspace(*end))
+ end--;
+ *(end + 1) = '\0';
+
+ while (*s && isspace(*s))
+ s++;
+
+ return s;
+}
+EXPORT_SYMBOL(strstrip);
+
#ifndef __HAVE_ARCH_STRLEN
/**
* strlen - Find the length of a string
--
1.3.0
^ permalink raw reply related
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Jakub Narebski @ 2006-04-25 9:10 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP116C6B217F25F2ADAF0C67AEBF0@CEZ.ICE>
sean wrote:
> On Tue, 25 Apr 2006 04:34:36 -0400
> sean <seanlkml@sympatico.ca> wrote:
>
>> If you're cherry-picking from a disposable branch, then you don't want to
>> include a link to it in your new commit. Once you include the link, the
>> source commit should be protected from pruning just like any other piece
>> of history. Otherwise there's no way for fsck-objects to know if a
>> missing
>> object means corruption or not. So you need a way at commit time to
>> request the explicit linkage.
>
> Actually this implies that anyone pulling just this branch would
> potentially
> also end up pulling large portions of other branches too. So maybe
> making
> them optional is The Right Thing. In which case, we'd just have to accept
> these as weaker than the parentage links and fsck-objects et. al. would
> have to tolerate such missing commits.
Actually, this can be resolved using automatic history grafts to the remote
repository we pulled from, if the commit is not present on local side (and
removing graft when commit appears on local side).
I was more concerned about size of repository required by keeping some parts
of history which would be purged without those "related" links. But your
concern (pulling) is more important.
--
Jakub Narebski
Warsaw, Poland
^ 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.