headers
Dave Jones | 1 Sep 2007 01:02
Picon
Favicon

Re: maturity and status and attributes, oh my!

On Fri, Aug 31, 2007 at 05:38:34PM -0400, Robert P. J. Day wrote:

 >   it may be that some people had a different understanding of what was
 > meant by "maturity" than i did.  what *i* meant by that attribute is
 > a feature's current position in the normal software life cycle, and
 > that would be one of:
 > 
 >   experimental -> normal (stable) -> deprecated -> obsolete

Life isn't so black and white.
 * We have stuff go into the tree that isn't experimental on a regular
   basis, due to proving outside of Linus' tree, be that in -mm, or
   a distro tree, or anywhere else.
 * We've had code become undeprecated a few times.
 * Likewise stuff has sometimes got so fucked up that it's become
   experimental again (see the longhaul driver for a great example
   of a catastrophe in motion).

 >   it's a natural progression and, at any point, a feature cannot
 > possibly have more than one maturity value.  it would be as absurd as
 > saying that someone was a teenager *and* was a twenty-something at the
 > same time.  not possible.

Again, not so black and white.
It's feasible that something can be experimental on one architecture,
stable on another (typically x86), or even deprecated on x86, but still
supported on other architectures.
It's not just a per arch thing either, in some cases, we've had
differing levels of maturity based upon other hardware constraints,
or even varying versions of system software.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan Cox | 1 Sep 2007 01:19
Picon

Re: sata_via: write errors on PATA drive connected to VT6421

On Sat, 1 Sep 2007 00:55:21 +0200
Ondrej Zary <linux <at> rainbow-software.org> wrote:

> Hello,
> I think that I've found and fixed the problem. There is a copy/paste bug in 
> vt6421_set_dma_mode() function which causes wrong values to be written to 
> PATA_UDMA_TIMING register.
> 
> 
> This patch fixes a copy/paste bug that breaks DMA modes on VT6421 PATA port.
> 
> Signed-off-by: Ondrej Zary <linux <at> rainbow-software.org>
> 
> --- linux-2.6.22.3-orig/drivers/ata/sata_via.c	2007-09-01 00:40:22.000000000 +0200
> +++ linux-2.6.22.3-router2/drivers/ata/sata_via.c	2007-09-01 00:10:40.000000000 +0200
>  <at>  <at>  -370,7 +370,7  <at>  <at> 
>  {
>  	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
>  	static const u8 udma_bits[] = { 0xEE, 0xE8, 0xE6, 0xE4, 0xE2, 0xE1, 0xE0, 0xE0 };
> -	pci_write_config_byte(pdev, PATA_UDMA_TIMING, udma_bits[adev->pio_mode - XFER_UDMA_0]);
> +	pci_write_config_byte(pdev, PATA_UDMA_TIMING, udma_bits[adev->dma_mode - XFER_UDMA_0]);
>  }
>  
>  static const unsigned int svia_bar_sizes[] = {

Acked-by: Alan Cox <alan <at> redhat.com>

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michal Piotrowski | 1 Sep 2007 01:13
Picon

Re: [ANNOUNCE] DeskOpt - on fly task, i/o scheduler optimization

On 01/09/2007, Chris Snook <csnook <at> redhat.com> wrote:
> Michal Piotrowski wrote:
> > Hi,
> >
> > Here is something that might be useful for gamers and audio/video editors
> > http://www.stardust.webpages.pl/files/tools/deskopt/
> >
> > You can easily tune CFS/CFQ scheduler params
>
> I would think that gamers and AV editors would want to be using deadline
> (or maybe even as), not cfq.  How well does it work with other I/O
> schedulers?

Actually it does not support other i/o schedulers (early stage of
development ;).

"Linux supports io scheduling priorities and classes since 2.6.13 with
the CFQ io scheduler." (ionice man page)

So we can only tune
antic_expire  est_time  read_batch_expire  read_expire
write_batch_expire  write_expire
for anticipatory and
fifo_batch  front_merges  read_expire  write_expire  writes_starved
for deadline.

I'll have a look on it.

>
>         -- Chris
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mitchell Erblich | 1 Sep 2007 01:29
Picon
Favicon

Re: maturity and status and attributes, oh my!

"Robert P. J. Day" wrote:
> 
>   at the risk of driving everyone here totally bonkers, i'm going to
> take one last shot at explaining what i was thinking of when i first
> proposed this whole "maturity level" thing.  and, just so you know,
> the major reason i'm so cranked up about this is that i'm feeling just
> a little territorial -- i was the one who first started nagging people
> to consider this idea, so i'm a little edgy when i see folks finally
> giving it some serious thought but appearing to get ready to implement
> it entirely incorrectly in a way that's going to ruin it irreparably
> and make it utterly useless.
> 
>   this isn't just about defining a single feature called "maturity".
> it's about defining a general mechanism so that you can add entirely
> new (what i call) "attributes" to kernel features.  one attribute
> could be "maturity", which could take one of a number of possible
> values.  another could be "status", with the same restrictions.
> heck, you could define the attribute "colour", and decide that various
> kernel features could be labelled as (at most) one of "red", "green"
> and "chartreuse."  that's what i mean by an "attribute", and
> attributes would have two critical and non-negotiable properties:
<<< snip>>>>
> 
>   but i hope i've flogged this thoroughly to the point where people
> can see what i'm driving at.  once you see (as in simon's patch) how
> to add the first attribute, it's trivial to simply duplicate that code
> to add as many more as you want.
> 
> rday
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Satyam Sharma | 1 Sep 2007 01:49
Favicon

Re: [Bugme-new] [Bug 8957] New: Exported functions and variables


On Fri, 31 Aug 2007, Matti Linnanvuori wrote:
> 
> It seems to me that kernel/module.c allows the whole kernel to use
> exported symbols during the execution of the init function if they are
> weak:
>                         /* Ok if weak.  */
>                           if (ELF_ST_BIND(sym[i].st_info) == STB_WEAK)
>                                   break;
> That seems a possible way to produce the scenario of this so-called bug.

No, even that won't reproduce the bug you're talking about, and you
clearly don't know how weak symbols are supposed to work / be used :-)
simplify_symbols() -> resolve_symbol() is called to resolve /external/
symbols that the module-being-loaded references, and error out in case
no such (global, exported) symbol was currently found.

So the "sym[i]" there refers to the (as yet unresolved) symbol referenced
in the _dependent module B_, that it sees exported as a weak symbol
(probably because marked as such in some header prototype). That check is
to support usage where we still allow B to load without A being loaded,
because it's somehow ensured that B will never call that function at
runtime unless it is available ... something like:

extern void mod_a_func(void) __attribute__((weak));
static int __init mod_b_init(void)
{
        if (mod_a_func)
                mod_a_func();
        else {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mingming Cao | 1 Sep 2007 02:01
Picon
Favicon

Re: [RFC 1/4] Large Blocksize support for Ext2/3/4

On Wed, 2007-08-29 at 17:47 -0700, Mingming Cao wrote:

> Just rebase to 2.6.23-rc4 and against the ext4 patch queue. Compile tested only. 
> 
> Next steps:
> Need a e2fsprogs changes to able test this feature. As mkfs needs to be
> educated not assuming rec_len to be blocksize all the time.
> Will try it with Christoph Lameter's large block patch next.
> 

Two problems were found when testing largeblock on ext3.  Patches to
follow. 

Good news is, with your changes, plus all these extN changes, I am able
to run ext2/3/4 with 64k block size, tested on x86 and ppc64 with 4k
page size. fsx test runs fine for an hour on ext3 with 16k blocksize on
x86:-)

Mingming
Permalink | Reply | 0 comments |
headers
Daniel Walker | 1 Sep 2007 02:01

Re: v2.6.23-rc4-rt1 / new project URL

On Fri, 2007-08-31 at 22:59 +0200, Thomas Gleixner wrote:
> We're pleased to announce the release of the v2.6.23-rc4-rt1 kernel,
> which can be downloaded from a new place:
>  
>    http://www.kernel.org/pub/linux/kernel/projects/rt/
>  
> The move to kernel.org is experimental for now, we'll keep it if it
> works out fine.
> 
> Changes since 2.6.23-rc2-rt2:
> 
> - update to -rc4
> - update to 2.6.23-rc4-hrt1
> 
> - UP compile fixes back merged (Kevin Hilman / Steven Rostedt)
> - various latency tracer fixes (Steven Rostedt)

I'm not sure which latency tracing fixes these are, but Steven's
get_monotonic_cycles() changes are racy .. It might be a little
premature to include them .. It at least fouls latency tracing on my
test machine.

> - simple_irq change (Kevin Hilman): needs more thought
> - RCU updates (Paul McKenney): needs proper integration
> - latency tracer changes (Daniel Walker): needs review
> - PICK_OP changes (Daniel Walker): needs review

The PICK_OP changes got reviewed by Ingo , as of,

http://marc.info/?l=linux-rt-users&m=118638506125380&w=2
(Continue reading)

Permalink | Reply | 6 comments |
headers
Mingming Cao | 1 Sep 2007 02:12
Picon
Favicon

[RFC 1/2] JBD: slab management support for large block(>8k)

>From clameter:
Teach jbd/jbd2 slab management to support >8k block size. Without this, it refused to mount on >8k ext3.

Signed-off-by: Mingming Cao <cmm <at> us.ibm.com>

Index: my2.6/fs/jbd/journal.c
===================================================================
--- my2.6.orig/fs/jbd/journal.c	2007-08-30 18:40:02.000000000 -0700
+++ my2.6/fs/jbd/journal.c	2007-08-31 11:01:18.000000000 -0700
 <at>  <at>  -1627,16 +1627,17  <at>  <at>  void * __jbd_kmalloc (const char *where,
  * jbd slab management: create 1k, 2k, 4k, 8k slabs as needed
  * and allocate frozen and commit buffers from these slabs.
  *
- * Reason for doing this is to avoid, SLAB_DEBUG - since it could
- * cause bh to cross page boundary.
+ * (Note: We only seem to need the definitions here for the SLAB_DEBUG
+ * case. In non debug operations SLUB will find the corresponding kmalloc
+ * cache and create an alias. --clameter)
  */
-
-#define JBD_MAX_SLABS 5
-#define JBD_SLAB_INDEX(size)  (size >> 11)
+#define JBD_MAX_SLABS 7
+#define JBD_SLAB_INDEX(size)  get_order((size) << (PAGE_SHIFT - 10))

 static struct kmem_cache *jbd_slab[JBD_MAX_SLABS];
 static const char *jbd_slab_names[JBD_MAX_SLABS] = {
-	"jbd_1k", "jbd_2k", "jbd_4k", NULL, "jbd_8k"
+	"jbd_1k", "jbd_2k", "jbd_4k", "jbd_8k",
+	"jbd_16k", "jbd_32k", "jbd_64k"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mingming Cao | 1 Sep 2007 02:12
Picon
Favicon

[RFC 2/2] JBD: blocks reservation fix for large block support

The blocks per page could be less or quals to 1 with the large block support in VM.
The patch fixed the way to calculate the number of blocks to reserve in journal in the
case blocksize > pagesize.

Signed-off-by: Mingming Cao <cmm <at> us.ibm.com>

Index: my2.6/fs/jbd/journal.c
===================================================================
--- my2.6.orig/fs/jbd/journal.c	2007-08-31 13:27:16.000000000 -0700
+++ my2.6/fs/jbd/journal.c	2007-08-31 13:28:18.000000000 -0700
 <at>  <at>  -1611,7 +1611,12  <at>  <at>  void journal_ack_err(journal_t *journal)

 int journal_blocks_per_page(struct inode *inode)
 {
-	return 1 << (PAGE_CACHE_SHIFT - inode->i_sb->s_blocksize_bits);
+	int bits = PAGE_CACHE_SHIFT - inode->i_sb->s_blocksize_bits;
+
+	if (bits > 0)
+		return 1 << bits;
+	else
+		return 1;
 }

 /*
Index: my2.6/fs/jbd2/journal.c
===================================================================
--- my2.6.orig/fs/jbd2/journal.c	2007-08-31 13:32:21.000000000 -0700
+++ my2.6/fs/jbd2/journal.c	2007-08-31 13:32:30.000000000 -0700
 <at>  <at>  -1612,7 +1612,12  <at>  <at>  void jbd2_journal_ack_err(journal_t *jou
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christoph Lameter | 1 Sep 2007 02:30
Picon
Favicon

Re: [PATCH 4/6] Filter based on a nodemask as well as a gfp_mask

Acked-by: Christoph Lameter <clameter <at> sgi.com>
Permalink | Reply | 0 comments |

Gmane