Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Crispin Cowan]

James Morris wrote:
> On Thu, 21 Jun 2007, Chris Mason wrote:  
>>> The incomplete mediation flows from the design, since the pathname-based
>>> mediation doesn't generalize to cover all objects unlike label- or
>>> attribute-based mediation.  And the "use the natural abstraction for
>>> each object type" approach likewise doesn't yield any general model or
>>> anything that you can analyze systematically for data flow.
>>>   
>> This feels quite a lot like a repeat of the discussion at the kernel
>> summit.  There are valid uses for path based security, and if they don't
>> fit your needs, please don't use them.  But, path based semantics alone
>> are not a valid reason to shut out AA.
>> 
> The validity or otherwise of pathname access control is not being 
> discussed here.
>
> The point is that the pathname model does not generalize, and that 
> AppArmor's inability to provide adequate coverage of the system is a 
> design issue arising from this.
>   
The above two paragraphs appear to contradict each other.

> Recall that the question asked by Lars was whether there were any 
> outstanding technical issues relating to AppArmor.
>
> AppArmor does not and can not provide the level of confinement claimed by 
> the documentation, and its policy does not reflect its actual confinement 
> properties.  That's kind of a technical issue, right?
>   
So if the document said "confinement with respect to direct file access
and POSIX.1e capabilities" and that list got extended as AA got new
confinement features, would that address your issue?

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: JIT emulator needs

[Albert Cahalan]

On 6/21/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:

On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
> Right now, Linux isn't all that friendly to JIT emulators.
> Here are the problems and suggestions to improve the situation.
>
> There is an SE Linux execmem restriction that enforces W^X.
> Assuming you don't wish to just disable SE Linux, there are
> two ugly ways around the problem. You can mmap a file twice,
> or you can abuse SysV shared memory. The mmap method requires
> that you know of a filesystem mounted rw,exec where you can
> write a very large temporary file. This arbitrary filesystem,
> rather than swap space, will be the backing store. The SysV
> shared memory method requires an undocumented flag and is
> subject to some annoying size limits. Both methods create
> objects that will fail to be deleted if the program dies
> before marking the objects for deletion.

and these methods also destroy yourself on any machine with a looser
cache coherency between I and D-cache

for all but x86 you pretty much have to do the mprotect() between the
two states to deal with the cache flushing properly...


If the instructions to force data write-back and/or to
invalidate the instruction cache are priveleged, yes.
AFAIK, only ARM is that lame.

For example, PowerPC lets unprivileged code run
the required instructions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] doc/oops-tracing: add Code: decode info

[Randy Dunlap]

From: Randy Dunlap <[EMAIL PROTECTED]>

Add info that the Code: bytes line contains  or (wxyz) in some
architecture oops reports and what that means.

Add URL for a script by Andi Kleen that reads the Code: line from an Oops
report file and generates assembly code from the hex bytes.
(This script does not handle Code: lines that contain  or (wxyz)
markings.)

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 Documentation/oops-tracing.txt |   15 +++
 1 file changed, 15 insertions(+)

--- linux-2.6.22-rc5.orig/Documentation/oops-tracing.txt
+++ linux-2.6.22-rc5/Documentation/oops-tracing.txt
@@ -86,6 +86,21 @@ stuff are the values reported by the Oop
 and do a replace of spaces to "\x" - that's what I do, as I'm too lazy 
 to write a program to automate this all).
 
+Alternatively, you can use the shell script from
+.  Usage is:
+decodecode  or (), as in "<86>" or "(f00d)".  These
+<> or () markings indicate the current instruction pointer.  Example from
+i386, split into multiple lines for readability:
+
+Code: f9 0f 8d f9 00 00 00 8d 42 0c e8 dd 26 11 c7 a1 60 ea 2b f9 8b 50 08 a1
+64 ea 2b f9 8d 34 82 8b 1e 85 db 74 6d 8b 15 60 ea 2b f9 <8b> 43 04 39 42 54
+7e 04 40 89 42 54 8b 43 04 3b 05 00 f6 52 c0
+
 Finally, if you want to see where the code comes from, you can do
 
cd /usr/src/linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: O_DIRECT, fdatasync_area, mwrite

[Reza Roboubi]

Reza Roboubi wrote:

Linus Torvalds:
 > I suspect that this is about a few hundred lines of code (and a lot of
 > testing). And you can emulate O_DIRECT behavior with it, along with
 > splice (only for page-cache entities, though), and a lot of other
 > off-by-one uses.
( http://lwn.net/2002/0516/a/lt-async.php3 )

I have often read this message and wondered why no one has implemented 
it yet.  We would love to have such clean features instead of O_DIRECT. 
 At this very moment it's a bit hard for us to do this(given a 
prerequisites learning curve amongst other factors.)  We may at some 
point do it and I'd love to contribute.  What _are_ the issues with it, 
 and is there a technical reason it hasn't been implemented yet by anybody?


Further, is O_DIRECT to raw partition also unclean?


I know the top guys are very busy;  but I'd appreciate just a brief 
comment on the present situation.


Reza.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in a driver while using SLUB as a SLAB allocator

[Hugh Dickins]

On Thu, 21 Jun 2007, Christoph Lameter wrote:
> On Fri, 22 Jun 2007, Hugh Dickins wrote:
> 
> > However... what gives you confidence that flush_dcache_page is
> > never applied to other slab pages?
> 
> Flush dcache page is supposed to run on pages not objects of varying 
> length. It is suprising that this has not lead to earlier problems.
> Objects allocated this way may straddle a page boundary under some 
> conditions and in that case virt_to_page may not lead to a page that 
> covers the complete object that is supposed to be flushed. Hopefully the 
> "size" of the allocated object were whole pages.

No, that's the wrong way round.  Neither ARM nor PA-RISC expects
flush_dcache_page to flush any dcache when given a slab allocation:
they just expect it to pass through, not to oops.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Chinese translation of Documentation/HOWTO

[Rob Landley]

On Thursday 21 June 2007 23:23:54 dave young wrote:
> Hi,
>
> 2007/6/22, Rob Landley <[EMAIL PROTECTED]>:
> > On Thursday 21 June 2007 10:40:17 Li Yang wrote:
> > > This is a Chinese translated version of Documentation/HOWTO.  Currently
> > > Chinese involvement in Linux kernel is very low, especially comparing
> > > to its largest population base.  Language could be the main obstacle. 
> > > Hope this document will help more Chinese to contribute to Linux
> > > kernel.
> >
> > I'm putting together a kernel documentation directory at
> > http://kernel.org/doc and I could easily add translations in there.  I
> > just don't know if this is a good idea.
>
> I think it's not a good idea to merge translations into kernel.
>
> > The problem is, the submission of patches happens on the various
> > kernel.org mailing lists, which are all in English.  Kernel development
> > is done in a single common language: English.  (If you'd like to argue
> > for it to be done in another language, please make the proposal in
> > Linus's native Swedish.)
>
> Yes, I agree with you, and there's so many other languages, It's
> better for someone to  create a standalone kdoc translation project
> than to merge them into kernel.

I wasn't suggesting merging them into the kernel.

I'm doing a web page to put together html versions of lots of kernel 
documentation in a place Google can find it.  Peter Anvin was kind enough to 
give me http://kernel.org/doc for this.  It would not be technically 
difficult for this web page to host translated versions of this 
documentation.

The question is, do the kernel developers want to encourage people who don't 
speak English to mess with the kernel, any more than they want to encourage 
kernel developers who don't know C?  Is kernel documentation in Chinese a 
better idea than a repository of kernel patches in C++?  (Either way, work 
resulting from this is much less likely than normal to be merged into the 
kernel.)

I don't know if this is a valid concern or not.  That's why I'm asking.

Rob

P.S.  The hardest part of putting together a kernel documentation web page is 
actually indexing it coherently.  It's not very useful to just dump together 
huge amounts of stuff from Documentation and make htmldocs and linux weekly 
news' kernel index and kerneltrap and kernel traffic and the kernelnewbies 
wiki and kernelplanet and man-pages-2.57 coverted to html with doclifter...  
Ahem.  I finally figured out how I wanted it indexed, made a skeleton to hang 
stuff on, and my laptop blew up.  Grrr.  Mostly recovered, but now OLS is 
bearing down on me and I still haven't got a new laptop...

Don't mind me, I'll catch up.
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Chinese translation of Documentation/HOWTO

[Rob Landley]

Dear Linus: you aren't at Transmeta anymore.  Here's a second attempt to cc: 
you on this because I need your opinion on a documentation issue:

On Thursday 21 June 2007 22:48:32 Rob Landley wrote:
> On Thursday 21 June 2007 10:40:17 Li Yang wrote:
> > This is a Chinese translated version of Documentation/HOWTO.  Currently
> > Chinese involvement in Linux kernel is very low, especially comparing to
> > its largest population base.  Language could be the main obstacle.  Hope
> > this document will help more Chinese to contribute to Linux kernel.
>
> I'm putting together a kernel documentation directory at
> http://kernel.org/doc and I could easily add translations in there.  I just
> don't know if this is a good idea.
>
> The problem is, the submission of patches happens on the various kernel.org
> mailing lists, which are all in English.  Kernel development is done in a
> single common language: English.  (If you'd like to argue for it to be done
> in another language, please make the proposal in Linus's native Swedish.)
>
> Setting aside for the moment version skew and coverage issues when
> translating Documentation, which aren't really serious blocking issues, my
> question is this:  If developers aren't fluent enough with English to
> follow the documentation, how can they follow any of the technical
> discussions necessary to merge their patches back into the mainstream
> kernel?  Doesn't this encourage the creation of patches that can't easily
> be merged back into the kernel?
>
> It could be that the answer is "no, it's fine".  I don't feel qualified to
> make this decision.  It's very easy for me to accept contributed
> translations and put them up, but I'd like some kind of consensus from the
> kernel developers that I SHOULD do this.  How much use is a Chinese version
> of a HOWTO that tells people how to interact with an English community?
>
> Could somebody more qualified than me speak up on this one so I know what
> to do?
>
> Rob
>
> P.S.  I meant to comment when this topic first came up last week
> [http://kerneltrap.org/node/8365] but my laptop's hard drive died and I
> lost the link.  (Along with any chance of this being a particularly
> productive month for me...)



-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in a driver while using SLUB as a SLAB allocator

[Christoph Lameter]

On Fri, 22 Jun 2007, Hugh Dickins wrote:

> But PA-RISC also has a function called flush_dcache_page, which uses
> page_mapping and expects a struct address_space * from it.  If that
> can ever be get applied to a SLOB page (which is not so clear as in
> the ARM case, but cannot easily be ruled out completely), we're
> in trouble without a PageSlab test within page_mapping.

A page comes from the page allocator. Access to a slab allocators "page" 
is an access to subsystem internals. Those internals vary 
(including the representation of objects in the "page") and depend on the 
slab allocator selected, the debug options in effect and parameters 
with which the slab was created etc etc.

If flush_dcache_page is applied to a slab object then we need to do a 
similar change to PA-RISC as for ARM.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Randy Dunlap]

On Fri, 22 Jun 2007 01:34:24 -0300 Alexandre Oliva wrote:

> > You're not going to make a happy, happy merging code sharing world
> > by fragmenting the licence landscape even more.
> 
> I take it that removing barriers to cooperation in GPLv3 by default is
> undesirable.  Well, then, what can I say?  I tried.  :-(

preferably that you give up.

Thanks.
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Al Viro]

On Fri, Jun 22, 2007 at 01:34:24AM -0300, Alexandre Oliva wrote:
> I take it that removing barriers to cooperation in GPLv3 by default is
> undesirable.  Well, then, what can I say?

That It's All Their[kernel developers'] Fault(tm), of course.

> I tried.  :-(

Or that, indeed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Kernel include files

[H. Peter Anvin]

David Woodhouse wrote:
>> The main problems are not really hard to fix..
>>
>> -Most problems eem to be related to the fact that Linux does not
>>  use C-99 based types in the kernel and the related type definitions 
>>  are not written in plain C. This is something that should be fixed
>>  with a source consolidation program or by defining aliases to 
>>  C-99 types in case the compiler is not GCC.
> 
> 
> The argument has been made that the standard C99 types are _optional_,
> and anything included from a C library's headers without _explicitly_
> being included by the user shouldn't define those types.
> 
> Personally, I think that's a load of bollocks. And it certainly doesn't
> apply to Linux-specific files like , which are perfectly
> entitled to use a C standard from last millennium, regardless of
> namespace 'pollution' issues. That's why we continue to use the crappy
> __u32 types. Can you be more specific about why this is a problem? Don't
> we mostly define those crappy types using arch-specific knowledge, as
> 'int', 'long', etc?
> 

It definitely does hurt when using those types in files that may want to
be used by the C library (as opposed to the end user.)

However, there is no reason why there should be anything funny about the
declaration of those types.

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Al Viro]

On Fri, Jun 22, 2007 at 01:26:54AM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote:
> >> Do you agree that if there's any single contributor who thinks it
> >> can't be tivoized, and he manages his opinion to prevail in court
> >> against a copyright holder, then it can't?  That this is the same
> >> privilege to veto additional permissions that Al Viro has just
> >> claimed?
> 
> > You know, I'm rapidly losing any respect for your integrity.  The only
> > "privelege" claimed is that of not relicensing one's contributions.
> 
> No, this thread was about additional permissions to combine with other
> licenses.  I didn't suggest anything about relicensing whatsoever,
> that's all noise out of not understanding the suggestion.

And that constitutes the change of license.  If you *really* do not understand
that, I'd recommend asking FSF legal folks, especially since you have
mentioned working on v3.  And that, BTW, is far more serious detail than
your affiliation (or lack thereof) with FSF.  Don't forget to bring a copy
of your posting that had started this thread when you talk to them.

And really, stop digging.  Please.  YANAL.  You are definitely not in
position to offer any specific changes in v3.  Are you seriously expecting
an ACK on your handwaving, when conditions mentioned in your patch to
license are not just vague as hell, but are 100% certain to be interpreted
in conflicting ways as shown by the previous thread?

What are you expecting, anyway?  "You guys can link to v3 code if you read
v2 as prohibiting tivoization, otherwise the code is withdrawn" != "some
people think that v2 prohibits it, some do not".  And somehow I doubt that
this change of situation will make the latter happy.

Besides, what you are suggesting is logistical nightmare.  Somebody in
v3 project changes borrowed v2 code.  Result is pulled back into Linux.
What is the license of that thing?  v3 with additional permission?  v2
with additional permission?  What happens if code is then rewritten, with
some pieces remaining from v3 changes?  Oh, you want to deal only with
entire modules?  And then both sides need to be damn careful not to copy
pieces across the module boundary?

Suppose ZFS _is_ pulled into the tree via that mechanism.  Just what
will happen if some code is massaged a bit, found generically useful
and lifted into a helper function?  Do other filesystems (v2 ones)
calling it suddenly get into patent violations?

Just what makes you think that anybody would like that kind of "cooperation"?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [DOCS] make headers_install

[David Woodhouse]

On Fri, 2007-06-22 at 00:04 -0400, Rob Landley wrote:
> Here's a really quick stab at documentation for make headers_install.
> 
> Comments?
> 
> 
> 
> Exporting kernel headers for use by userspace (/usr/include/linux)

Also /usr/include/asm (and asm-* on biarch 64-bit architectures), along
with a few other directories. See $linux/include/Kbuild.

Other than that it looks relatively sane; thanks.

-- 
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in a driver while using SLUB as a SLAB allocator

[Christoph Lameter]

On Fri, 22 Jun 2007, Hugh Dickins wrote:

> You keep on forcing the outside world to revolve around your needs
> within slub.c: that is a good way to keep slub lean, and may be
> justified; but it's at least questionable to be enforcing such
> restrictions years after people have grown accustomed to more
> freedom from their slabs.

This work is a cleanup of the VM code and part of the slab cleanup that 
was done. Having slab objects on the LRU and other components of the VM 
that are supposed to work on page sized objects is plainly wrong and can 
lead to surprising results.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in a driver while using SLUB as a SLAB allocator

[Hugh Dickins]

On Thu, 21 Jun 2007, Christoph Lameter wrote:
> On Thu, 21 Jun 2007, Hugh Dickins wrote:
> 
> > Seems a little odd that it's gone throughout 2.6.22-rc unnoticed
> > until now - nobody else trying SLUB on ARM or PA-RISC yet perhaps.
> 
> The impact is only on a subset of ARM machines.
> 
> PA_RISC? It looks like they run their own flushing function for byte 
> ranges called flush_kernel_dache_range. That does not use the page struct.

PA-RISC does have a function of that name, and I'm guessing that
you came across it in looking at the PA-RISC dma_map_single.

But PA-RISC also has a function called flush_dcache_page, which uses
page_mapping and expects a struct address_space * from it.  If that
can ever be get applied to a SLOB page (which is not so clear as in
the ARM case, but cannot easily be ruled out completely), we're
in trouble without a PageSlab test within page_mapping.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in a driver while using SLUB as a SLAB allocator

[Christoph Lameter]

On Fri, 22 Jun 2007, Hugh Dickins wrote:

> However... what gives you confidence that flush_dcache_page is
> never applied to other slab pages?

Flush dcache page is supposed to run on pages not objects of varying 
length. It is suprising that this has not lead to earlier problems.
Objects allocated this way may straddle a page boundary under some 
conditions and in that case virt_to_page may not lead to a page that 
covers the complete object that is supposed to be flushed. Hopefully the 
"size" of the allocated object were whole pages.

> This looks to me like a clean way forward to try in -mm; but that
> 2.6.22 should go with the safety PageSlab test in page_mapping.

2.6.22 cleans up these issues and this one follows in those footsteps.

The reason for the introduction of the quicklist f.e. was to have a clear 
separation between page sized allocation and the variable allocations 
through slab allocators.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Chinese translation of Documentation/HOWTO

[WANG Cong]

On Fri, Jun 22, 2007 at 11:58:58AM +0800, Li Yang-r58472 wrote:
>> -Original Message-
>> From: Rob Landley [mailto:[EMAIL PROTECTED]
>> Sent: Friday, June 22, 2007 10:49 AM
>> 
>> On Thursday 21 June 2007 10:40:17 Li Yang wrote:
>> > This is a Chinese translated version of Documentation/HOWTO.
>Currently
>> > Chinese involvement in Linux kernel is very low, especially
>comparing to
>> > its largest population base.  Language could be the main obstacle.
>Hope
>> > this document will help more Chinese to contribute to Linux kernel.
>> 
>> I'm putting together a kernel documentation directory at
>http://kernel.org/doc
>> and I could easily add translations in there.  I just don't know if
>this is a
>> good idea.
>> 
>> The problem is, the submission of patches happens on the various
>kernel.org
>> mailing lists, which are all in English.  Kernel development is done
>in a
>> single common language: English.  (If you'd like to argue for it to be
>done
>> in another language, please make the proposal in Linus's native
>Swedish.)
>> 
>> Setting aside for the moment version skew and coverage issues when
>translating
>> Documentation, which aren't really serious blocking issues, my
>question is
>> this:  If developers aren't fluent enough with English to follow the
>> documentation, how can they follow any of the technical discussions
>necessary
>> to merge their patches back into the mainstream kernel?  Doesn't this
>> encourage the creation of patches that can't easily be merged back
>into the
>> kernel?
>
>So as I argued in a previous email, non-native English speakers tend to
>be more confused by the policies and processes.  I also don't think it's
>necessary to translate the technical documents.  To be a software
>developer, one has to be educated or experienced in technical terms.
>Technical discussion can be done without too much requirement to grammar
>and emotional expressing.  The translated document of policies and
>processes will help these people to understand the process better and go
>smoother in the process.
>

Yes, I agree.

Many people from China are trying to contribute to Linux kernel (like me),
a Chinese document which describes and explains the non-technical things
needed by Linux kernel will help them _much_ to join the development soon.
Also, IMO, a translation shows Linux kernel is friendly and open to
people from all over the world.

Regards!


WANG Cong

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[david]

On Thu, 21 Jun 2007, Joshua Brindle wrote:


[EMAIL PROTECTED] wrote:

 On Thu, 21 Jun 2007, Joshua Brindle wrote:

>  Lars Marowsky-Bree wrote:
> >   On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> >   
> > 
> > 
> > >   Um, no.  It might not be able to directly open files via that 
> >  path, but
> > >   showing that it can never read or write your mail is a rather 
> >  different

> > >   matter.
> > > 
> >   Yes. Your use case is different than mine.
> > 
> 
>  So.. your use case is what? If an AA user asked you to protect his mail 
>  from his browser I'm sure you'd truthfully answer "no, we can't do that 
>  but we can protect the path to your mail from your browser".. I think 
>  not. One need only look at the wonderful marketing literature for AA to 
>  see what you are telling people it can do, and your above statement 
>  isn't consistent with that, sorry.


 remember, the policies define a white-list



Except for unconfined processes.


correct, but we are talking about what a confined process can get to 
without assistance from an unconfined process.



 so if a hacker wants to have mozilla access the mail files he needs to get
 some other process on the sysstem to create a link or move a file to a
 path that mozilla does have access to. until that is done there is no way
 for mozilla to access the mail through the filesystem.

 other programs could be run that would give mozilla access to the mail
 contents, but it would be through some other path that the policy
 permitted mozilla accessing in the first place.

Or through IPC or the network, that is the point, filesystem only coverage 
doesn't cut it; there is no way to say the browser can't access the users 
mail in AA, and there never will be.


AA can be extended to cover these things in the future.

remember 'release early release often'?
how about 'perfect is the enemy of good enoug'?

at this point they're trying to get the initial implementation in so that 
people can start takeing advantage of it. As a side effect the cost of 
maintaining it will decrease, and they can put effort into planning future 
enhancements.


besides, as far as the network communication goes, doesn't netfilter now 
have a way to make rules for specific processes? if they don't then it 
could be added, but the details of the implementation would probably be 
very different from the current AA file controls.


how does delaying the acceptance of the current implementation encourage 
the additional features being added?


but to answer your two comments.

how does mozilla access your mail over the network without first capturing 
your password from somewhere?


as far as IPC goes, unix sockets are unavailable (AA as-is will control 
them), so you must be talking about signals or shared memory as the IPC 
mechanisms that mozilla would use to access your mail.


please explain to me what mail client you are useing that exposes your 
mail via these mechinsms.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Jan Harkes]

On Fri, Jun 22, 2007 at 01:14:27AM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:
> > On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
> >> It's not like anyone can safely tivoize devices with GPLv2 already, 
> 
> > So you really didn't pay any attention to anything people told you?
> 
> Yes.  Particularly to what Alan Cox and his legal counsel told me.  A
> single copyright holder able and willing to enforce the license
> against tivoization is enough.  What part of this don't you
> understand?
> 
> > The license does not grant the right that you will be able to run the
> > software on any particular platform or whether it will even work at all.
> 
> It doesn't grant TiVo the right to distribute the program without
> corresponding source code.
> 
> They fail to distribute the source code to the functional signature
> derived from the kernel binary.
> 
> Kaboom!

A signature is not a creative work and as such not covered by copyright.

At the moment the only protection that the signature/key has is that of
a trade secret, the GPLv2 does not cover that type of intellectual
propery and does not grant the licensee access to trade secrets.

Show me any case law that indicates otherwise. Maybe the content
producers will at some point manage to establish that encryption keys
and signatures are somehow copyrightable, but until a court of law
makes that determination there is no kaboom here.

> As for the right to run the program, I've also explained why in
> Brazilian copyright law this is a right granted by the license,
> because the license says that right is unrestricted.
>
> Kaboom!

No, the license says that it does not address the right to run a
program, and states that the license does not impose restrictions.
That is quite different from saying that the right is unrestricted.

So again, not much of a kaboom here either.

> > A mutual compatibility agreement (sublicense) would effectively
> > terminate any rights granted by the GPLv2,
> 
> Additional permissions to combine are not permission to relicense.
> Look at section 13 of GPLv3dd4 and of Affero GPLv3dd1.  That's the
> sort of additional permission I'm talking about here.

I'm talking about the GPLv2, so it doesn't matter what the GPLv3 says
wrt. additional permissions. Even if GPLv2 and GPLv3 grant the same
freedoms (permissions), the collective work would have additional
restrictions because of the GPLv3 code and as such the combined work
would result in a sublicensing of the GPLv2 licensed code, which is
explicitly not permitted.

> The same kind of additional permission that GPLed projects that use
> openssl adopt.

If they are the original author they can make that decision, just like
authors can dual-license, or decide to license their code as GPLv2+. It
is kind of funny how they phrase the exception as granting permission to
link against OpenSSL, where in reality they accept the added restriction
that results from the advertising clause of the BSD license. (i.e.
instead of granting you an additional freedom, they chose to remove the
freedom to modify the part of the code that advertises).

However with the openssl case there is no tight coupling because openssl
is a separate library. Some people have argued that the LGPL was never
really necessary because (unlike static libraries) shared libraries are
still separable from the GPL'd program.

Furthermore, those projects are not pulling individual source files from
into their project. There are also alternative crypto libraries (gnutls,
nessie) which can in many cases easily replace the openssl dependency.

Finally the original author accepts the additional restriction that
comes from the BSD + advertising clause, while the GPLv2 authors do not
accept the additional restrictions they would inherit from the GPLv3
otherwise they would re-license their code to GPLv2+.

Jan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in a driver while using SLUB as a SLAB allocator

[Hugh Dickins]

On Thu, 21 Jun 2007, Christoph Lameter wrote:

> Maybe this will address the issue on ARM?

Looks like it would indeed address the immediate issue on ARM -
IF they've no particular reason to be using kmalloc there.

However... what gives you confidence that flush_dcache_page is
never applied to other slab pages?

This looks to me like a clean way forward to try in -mm; but that
2.6.22 should go with the safety PageSlab test in page_mapping.

Hugh

> 
> 
> ARM: Allocate dma pages via the page allocator and not via the slab allocator
> 
> Slab allocations are not guaranteed to be page aligned and slab allocators
> may use the page structs for their own purposes. Using the page allocator
> yields a properly aligned page and also makes the page flushing logic work 
> right.
> 
> Passing a kmalloced "page" to a flushing function will not work reliably.
> 
> This will hopefully address the issue with SLUB on ARM. SLUB uses the
> page->mapping field which is also checked by the flushing logic. The
> flushing logic expects a normal page and not a slab page.
> 
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
> 
> ---
>  arch/arm/mm/consistent.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6/arch/arm/mm/consistent.c
> ===
> --- linux-2.6.orig/arch/arm/mm/consistent.c   2007-06-21 18:18:15.0 
> -0700
> +++ linux-2.6/arch/arm/mm/consistent.c2007-06-21 18:29:16.0 
> -0700
> @@ -277,7 +277,7 @@ dma_alloc_coherent(struct device *dev, s
>   if (arch_is_coherent()) {
>   void *virt;
>  
> - virt = kmalloc(size, gfp);
> + virt = get_free_pages(gfp, get_order(size));
>   if (!virt)
>   return NULL;
>   *handle =  virt_to_dma(dev, virt);
> @@ -364,7 +364,7 @@ void dma_free_coherent(struct device *de
>   WARN_ON(irqs_disabled());
>  
>   if (arch_is_coherent()) {
> - kfree(cpu_addr);
> + free_pages((unsigned long)cpu_addr, get_order(size));
>   return;
>   }
>  
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86_64: Fix misplaced `continue' in mce.c

[Randy Dunlap]

On Thu, 21 Jun 2007 17:13:49 -0700 (PDT) Joshua Wise wrote:

> Testing:
>   On my system, I could replicate the bug with the following command:
> # for i in `seq 15000`; do ./inject_sbe.sh; done
>   where inject_sbe.sh contains commands to inject a single-bit error into the
>   next memory write transaction.

Hi,

Does inject_sbe.sh require special hardware?  If so, what hardware
is it?

Thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Chinese translation of Documentation/stable_api_nonsense.txt

[WANG Cong]

On Fri, Jun 22, 2007 at 01:20:36AM +0800, TripleX wrote:
>This is a Chinese translated version of 
>Documentation/stable_api_nonsense.txt. Hope this document will be hepful.
>
>---
>Documentation/zh_CN/stable_api_nonsense.txt |  157 
>+++
>1 files changed, 157 insertions(+), 0 deletions(-)
>create mode 100644 Documentation/zh_CN/stable_api_nonsense.txt
>
>diff --git a/Documentation/zh_CN/stable_api_nonsense.txt 
>b/Documentation/zh_CN/stable_api_nonsense.txt
>new file mode 100644
>index 000..b03c750
>--- /dev/null
>+++ b/Documentation/zh_CN/stable_api_nonsense.txt

Signed-off-by: WANG Cong <[EMAIL PROTECTED]>


Thanks! Looks nice this time.

Er, you forgot your signed-off-by?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 21, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote:

> Great, so for ever and ever afterwards the code would have to keep a
> clear separation between the bits that are under different licences and
> make sure that no re-factor ever blurred the lines between them enough
> that you had trouble telling which was which.

As long as you care about being able to tell which is which, yes.  I
can understand why, under some circumstances, this might be taken as
worse than not being able to use code under GPLv3 (or any other
incompatible license) at all.

> understand what licence the final work is under.

If it's a mingled combination of code under GPLv2 plus permission to
combine with v3, and GPLv3 plus (potential built-in?) permission to
combine with v2, these are the combined terms.  You can still use it
with code under GPLv2 plus permission to combine with v3, and with
GPLv3 plus (potential built-in?) permission to combine with v2.  I can
see that it boggles the minds not used to this kind of combination.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 21, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote:

> None of this "Projects" nonsense.

The reason I mentioned projects was because each project has its
policies, around the interests of its own community.  Each project can
thus make a decision about its own policies, just like Linux has made
its own decisions.

It was not my intent to suggest that developers in certain projects
(communities, groups, however you want to name that) should grant
permissions for cooperation with other specific projects, even though
this is certainly something that can be done under copyright law.

So don't read too much into "project", think of it as "policy in a
particular community of developers", and note that the terms I
suggested didn't make any reference whatsoever to projects, but rather
to licenses (part of the policy of each project).

> Suddenly using other GPLv2 code becomes fraught with "which path did
> I obtain this licence down" games

I don't see how this could possibly be come up as a consequence of my
suggestion.  In fact, it is my understanding that the path is not
relevant, what matters is the terms under which the copyright holders
are willing to license their code.  That someone might be able to
enforce stricter terms upon a combined work is just a consequence of
the "most restrictive license" rule, not of the path the code
followed.  But IANAL.

> You're not going to make a happy, happy merging code sharing world
> by fragmenting the licence landscape even more.

I take it that removing barriers to cooperation in GPLv3 by default is
undesirable.  Well, then, what can I say?  I tried.  :-(

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote:

> On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote:
>> Do you agree that if there's any single contributor who thinks it
>> can't be tivoized, and he manages his opinion to prevail in court
>> against a copyright holder, then it can't?  That this is the same
>> privilege to veto additional permissions that Al Viro has just
>> claimed?

> You know, I'm rapidly losing any respect for your integrity.  The only
> "privelege" claimed is that of not relicensing one's contributions.

No, this thread was about additional permissions to combine with other
licenses.  I didn't suggest anything about relicensing whatsoever,
that's all noise out of not understanding the suggestion.

You objected to granting additional permissions.  You have that right,
per copyright law, and the other developers can then decide between
not granting an additional permission or removing all the code you
contributed such that they can.  That's veto.

Similarly, if someone proposed an additional unambiguous permission to
tivoize under GPLv2, any developer who objected to it could veto it
(the alternative being to remove all of his contributions).

> What really gets me is that you know it.

Yes.  The only disagreement is that I'm talking "additional permission
to combine" and you seem to keep understanding "relicensing", even
though these are very different concepts, with significantly different
consequences.

What they have in common is that you can veto either one with your
status as copyright holder, and that they would both permit some forms
of cooperation.

Permission to relicense would provide for one-way cooperation out of
Linux.  I'm not proposing this.  That would be stupid.  You've already
decided about it.  I respect that decision.  I even understand why you
made that decision.

Relicensing would provide for two-way cooperation, but under terms
that you don't consider acceptable.  You've pretty much already
decided not to do it.  I respect that decision.  I even understand why
you made that decision.

Permission to combine in both sides would provide for two-way
cooperation in ways that enable each author to enforce the terms s/he
chose for his/her own contributions.  This would address many of the
concerns raised about relicensing, and would increase the amount of
contributions in kind you can get.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in a driver while using SLUB as a SLAB allocator

[Hugh Dickins]

On Thu, 21 Jun 2007, Christoph Lameter wrote:
> On Thu, 21 Jun 2007, Hugh Dickins wrote:
> 
> > > The oops seems to occur after a page unmapping using dma_unmap_page() 
> > > followed
> > > by a flush_dcache_page() (in at91mci_post_dma_read()).
> 
> Was the page allocated using slab calls?

You've found yes (in the ARM case).

> Well one may be better off allocating pages using the page allocator 
> instead of the slab allocator. I removed these things from i386 but I did 
> not check ARM.

They may or may not be: I think that's a matter to discuss with rmk.

You keep on forcing the outside world to revolve around your needs
within slub.c: that is a good way to keep slub lean, and may be
justified; but it's at least questionable to be enforcing such
restrictions years after people have grown accustomed to more
freedom from their slabs.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Theodore Tso]

On Fri, Jun 22, 2007 at 02:34:17AM +0100, Al Viro wrote:
> What really gets me is that you know it.  And you know that just about
> everyone here knows it.  Yet you keep playing with rather pathetic
> attempts of innuendo and misdirection, when it's bloody obvious that
> you won't even get a PR win out of the entire mess you've been sustaining
> for about a week already (seriously, count postings in these threads).

I'm not sure Alexandre realizes it, but by his carrying on and on and
on with his really poorly reasoned arguments (I may disagree with
Eben's positions, but he's a much more reasonable debator and advocate
for the FSF's positions), Mr. Oliva, Latin America Board Member and
Free Software Evangelist, has probably made it made it much more
*unlikely* that the Linux kernel will ever go GPLv3.

About a week and half ago, Linus was saying he was a pragmatist and if
there was a good enough reason (such as if Solaris adopting GPLv3 and
there being aufficiently interesting technology that it would be worth
the code exchange), there was a chance that he might be for it.  But
Alexandre has been so annoying and so obtuse, that people's positions
have hardened to the point where I doubt kernel developers would be
willing to go for at this point.  Something that went from being
merely extremely unlikely has become "practically impossible".

> The first law of holes: when you are in one, stop digging...

Indeed.

Another law of negotiations --- don't goad people into hardening their
positions; it helps neither you nor your interests.

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] Chinese translation of Documentation/HOWTO

[Bryan Wu]

On Fri, 2007-06-22 at 11:58 +0800, Li Yang-r58472 wrote:
> > -Original Message-
> > From: Rob Landley [mailto:[EMAIL PROTECTED]
> > Sent: Friday, June 22, 2007 10:49 AM
> > 
> > On Thursday 21 June 2007 10:40:17 Li Yang wrote:
> > > This is a Chinese translated version of Documentation/HOWTO.
> Currently
> > > Chinese involvement in Linux kernel is very low, especially
> comparing to
> > > its largest population base.  Language could be the main obstacle.
> Hope
> > > this document will help more Chinese to contribute to Linux kernel.
> > 
> > I'm putting together a kernel documentation directory at
> http://kernel.org/doc
> > and I could easily add translations in there.  I just don't know if
> this is a
> > good idea.
> > 
> > The problem is, the submission of patches happens on the various
> kernel.org
> > mailing lists, which are all in English.  Kernel development is done
> in a
> > single common language: English.  (If you'd like to argue for it to be
> done
> > in another language, please make the proposal in Linus's native
> Swedish.)
> > 
> > Setting aside for the moment version skew and coverage issues when
> translating
> > Documentation, which aren't really serious blocking issues, my
> question is
> > this:  If developers aren't fluent enough with English to follow the
> > documentation, how can they follow any of the technical discussions
> necessary
> > to merge their patches back into the mainstream kernel?  Doesn't this
> > encourage the creation of patches that can't easily be merged back
> into the
> > kernel?
> 
> So as I argued in a previous email, non-native English speakers tend to
> be more confused by the policies and processes.  I also don't think it's
> necessary to translate the technical documents.  To be a software
> developer, one has to be educated or experienced in technical terms.
> Technical discussion can be done without too much requirement to grammar
> and emotional expressing.  The translated document of policies and
> processes will help these people to understand the process better and go
> smoother in the process.
> 
> - Leo

Leo is right. Policies and processes should be clear for all developer
including non-native English speakers, while other technical documents
do not need to be translated.

After I read the translations, I also found something I missed before.

Thanks for the work
- Bryan Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 21, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:

> On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
>> It's not like anyone can safely tivoize devices with GPLv2 already, 

> So you really didn't pay any attention to anything people told you?

Yes.  Particularly to what Alan Cox and his legal counsel told me.  A
single copyright holder able and willing to enforce the license
against tivoization is enough.  What part of this don't you
understand?

> The license does not grant the right that you will be able to run the
> software on any particular platform or whether it will even work at all.

It doesn't grant TiVo the right to distribute the program without
corresponding source code.

They fail to distribute the source code to the functional signature
derived from the kernel binary.

Kaboom!


As for the right to run the program, I've also explained why in
Brazilian copyright law this is a right granted by the license,
because the license says that right is unrestricted.

Kaboom!

> There is no need to take out contributions because the GPLv2 does
> not prevent tivoization.

Says you (or perhaps you're just repeating what you heard and want to
believe).

But what did your lawyer say about it?  In reference to which
jurisdiction?

> A mutual compatibility agreement (sublicense) would effectively
> terminate any rights granted by the GPLv2,

Additional permissions to combine are not permission to relicense.
Look at section 13 of GPLv3dd4 and of Affero GPLv3dd1.  That's the
sort of additional permission I'm talking about here.

The same kind of additional permission that GPLed projects that use
openssl adopt.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 1/6] Convert the RCU tasklet into a softirq

[Steven Rostedt]

I believe this was originally done by Dipankar Sarma. I pulled these
changes from the -rt kernel.

For better preformance, RCU should use a softirq instead of a
tasklet.

Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>

Index: linux-2.6-test/include/linux/interrupt.h
===
--- linux-2.6-test.orig/include/linux/interrupt.h
+++ linux-2.6-test/include/linux/interrupt.h
@@ -245,6 +245,9 @@ enum
 #ifdef CONFIG_HIGH_RES_TIMERS
HRTIMER_SOFTIRQ,
 #endif
+   RCU_SOFTIRQ,/* Preferable RCU should always be the last softirq */
+   /* Entries after this are ignored in split softirq mode */
+   MAX_SOFTIRQ,
 };
 
 /* softirq mask and active fields moved to irq_cpustat_t in
Index: linux-2.6-test/kernel/rcupdate.c
===
--- linux-2.6-test.orig/kernel/rcupdate.c
+++ linux-2.6-test/kernel/rcupdate.c
@@ -67,7 +67,6 @@ DEFINE_PER_CPU(struct rcu_data, rcu_data
 DEFINE_PER_CPU(struct rcu_data, rcu_bh_data) = { 0L };
 
 /* Fake initialization required by compiler */
-static DEFINE_PER_CPU(struct tasklet_struct, rcu_tasklet) = {NULL};
 static int blimit = 10;
 static int qhimark = 1;
 static int qlowmark = 100;
@@ -253,7 +252,7 @@ static void rcu_do_batch(struct rcu_data
if (!rdp->donelist)
rdp->donetail = >donelist;
else
-   tasklet_schedule(_cpu(rcu_tasklet, rdp->cpu));
+   raise_softirq(RCU_SOFTIRQ);
 }
 
 /*
@@ -405,7 +404,6 @@ static void rcu_offline_cpu(int cpu)
_cpu(rcu_bh_data, cpu));
put_cpu_var(rcu_data);
put_cpu_var(rcu_bh_data);
-   tasklet_kill_immediate(_cpu(rcu_tasklet, cpu), cpu);
 }
 
 #else
@@ -417,7 +415,7 @@ static void rcu_offline_cpu(int cpu)
 #endif
 
 /*
- * This does the RCU processing work from tasklet context. 
+ * This does the RCU processing work from softirq context.
  */
 static void __rcu_process_callbacks(struct rcu_ctrlblk *rcp,
struct rcu_data *rdp)
@@ -462,7 +460,7 @@ static void __rcu_process_callbacks(stru
rcu_do_batch(rdp);
 }
 
-static void rcu_process_callbacks(unsigned long unused)
+static void rcu_process_callbacks(struct softirq_action *unused)
 {
__rcu_process_callbacks(_ctrlblk, &__get_cpu_var(rcu_data));
__rcu_process_callbacks(_bh_ctrlblk, &__get_cpu_var(rcu_bh_data));
@@ -526,7 +524,7 @@ void rcu_check_callbacks(int cpu, int us
rcu_bh_qsctr_inc(cpu);
} else if (!in_softirq())
rcu_bh_qsctr_inc(cpu);
-   tasklet_schedule(_cpu(rcu_tasklet, cpu));
+   raise_softirq(RCU_SOFTIRQ);
 }
 
 static void rcu_init_percpu_data(int cpu, struct rcu_ctrlblk *rcp,
@@ -549,7 +547,7 @@ static void __devinit rcu_online_cpu(int
 
rcu_init_percpu_data(cpu, _ctrlblk, rdp);
rcu_init_percpu_data(cpu, _bh_ctrlblk, bh_rdp);
-   tasklet_init(_cpu(rcu_tasklet, cpu), rcu_process_callbacks, 0UL);
+   open_softirq(RCU_SOFTIRQ, rcu_process_callbacks, NULL);
 }
 
 static int __cpuinit rcu_cpu_notify(struct notifier_block *self,

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 4/6] Make DRM use the tasklet is-sched API

[Steven Rostedt]

Update the DRM driver to use the new tasklet API, which does not rely
on the tasklet implementation details.

Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>


Index: linux-2.6.21-rt9/drivers/char/drm/drm_irq.c
===
--- linux-2.6.21-rt9.orig/drivers/char/drm/drm_irq.c
+++ linux-2.6.21-rt9/drivers/char/drm/drm_irq.c
@@ -461,7 +461,7 @@ void drm_locked_tasklet(drm_device_t *de
static DECLARE_TASKLET(drm_tasklet, drm_locked_tasklet_func, 0);
 
if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ) ||
-   test_bit(TASKLET_STATE_SCHED, _tasklet.state))
+   tasklet_is_scheduled(_tasklet))
return;
 
spin_lock_irqsave(>tasklet_lock, irqflags);

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[DOCS] make headers_install

[Rob Landley]

Here's a really quick stab at documentation for make headers_install.

Comments?



Exporting kernel headers for use by userspace (/usr/include/linux)

The "make headers_install" command exports the kernel's header files in a
form suitable for use by userspace programs. 

The linux kernel's exported header files describe the API for user space
programs attempting to use kernel services.  These kernel header files are
used by the system's C library (such as glibc or uClibc) to define available
system calls, as well as constants and structures to be used with these
system calls.  The C library's header files include the kernel header files
from the "linux" subdirectory.  The system's libc headers are usually
installed at the default location /usr/include and the kernel headers at
/usr/include/linux.

Kernel headers are backwards compatible, but not forwards compatible.  This
means that a program built against a C library using older kernel headers
should run on a newer kernel (although it may not have access to new
features), but a program built against newer kernel headers may not work on an
older kernel.

The "make headers_install" command can be run in the top level directory of 
the
kernel source code (or using a standard out-of-tree build).  It takes two
optional arguments:

  make headers_install ARCH=i386 INSTALL_HDR_PATH=/usr/include

ARCH indicates which architecture to produce headers for, and defaults to the
current architecture.  The linux/asm directory of the exported kernel headers
is platform-specific, to see a complete list of supported architectures use
the command:

  ls -d include/asm-* | sed 's/.*-//'

INSTALL_HDR_PATH indicates where to install the headers.  It defaults to
"./usr/include".

The command "make headers_install_all" exports headers for all architectures
simultaneously.  (This is mostly of interest to distribution maintainers,
who create an architecture-independent tarball from the resulting include
directory.)  Remember to provide the appropriate linux/asm directory via "mv"
or "ln -s" before building a C library with headers exported this way.

The kernel header export infrastructure is maintained by David Woodhouse
<[EMAIL PROTECTED]>.

-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 0/6] Convert all tasklets to workqueues

[Steven Rostedt]

There's a very nice paper by Matthew Willcox that describes Softirqs,
Tasklets, Bottom Halves, Task Queues, Work Queues and Timers[1].
In the paper it describes the history of these items.  Softirqs and
tasklets were created to replace bottom halves after a company (Mindcraft)
showed that Microsoft on a 4x SMP box would out do Linux. It was discovered
that this was due to a bottle neck caused by the design of Bottom Halves.
So Alexey Kuznetsov and Dave Miller [1] (and I'm sure others) created
softirqs and tasklets to multithread the bottom halves.

This worked well, and for the time it shut-up Microsoft^WMindcraft from
saying Linux was slow at networking.

Time passed, and Linux developed other nifty tools, like kthreads and
work queues. These run in a process context and are not as menacing to
latencies as softirqs and tasklets are.  Specifically, a tasklet,
acts as a task by only being able to run the function on one CPU
at a time. The same tasklet can not run on multiple CPUS.  So in that
aspect it is like a task (a task can only exist on one CPU at a time).
But a tasklet is much harder on the rest of the system because it
runs in interrupt context.  This means that if a higher priority process
wants to run, it must wait for the tasklet to finish before doing so.

The most part, tasklets today are not used for time critical functions.
Running tasklets in thread context is not harmful to performance of
the overall system. But running them in interrupt context is, since
they increase the overall latency for high priority tasks.

Even in Matthew's paper, he says that work queues have replaced tasklets.
But this is not truly the case.  Tasklets are common and plentiful.
But to go and replace each driver that uses a tasklet with a work queue
would be very painful.

I've developed this way to replace all tasklets with work queues without
having to change all the drivers that use them.  I created an API that
uses the tasklet API as a wrapper to a work queue.  This API doesn't need
to be permanent. It shows 1) that work queues can replace tasklets, and
2) we can remove a duplicate functionality from the kernel.  This API
only needs to be around until we removed all uses of tasklets from
all drivers.

I just want to state that tasklets served their time well. But it's time
to give them an honorable discharge.  So lets get rid of tasklets and
given them a standing salute as they leave :-)


This patch series does the following:

1) Changes the RCU tasklet into a softirq. The RCU tasklet *is* a 
performance critical function, and changing it to a softirq gives it
even more performance, and removes overhead. This has already been done
in the RT kernel, and should be applied regardless of the rest of the
patches in the series.

2) Splits out the tasklets from softirq.c.  This too should be done anyways.
Tasklets are not softirqs, and they have their own semantics that they
deserve their own file. Also it makes it a lot cleaner to replace them
with something else :-)

3/4) Add an API to the tasklets to allow a driver to see if a tasklet
is scheduled.  The DRM driver does it's own little thing with tasklets
and reads into the internals of the tasklet. These patches give the
DRM driver an API to do that a little bit cleaner.

The above patches really should go into the kernel if for any other
reason as a clean up patch set.

5) Move tasklet.h to tasklet_softirq.h and have tasklet.h include it.

6) This is the magic to make tasklets into work queues. It allows for
the kernel to be configured either with the normal tasklets, as it is
today, or with the tasklets-as-work-queues.

I've booted these patches on 5 machines, i386 and x86_64, and when
I can get my powerbook loaded with Linux, I'll try it there too.

I'd like to give thanks to Ingo Molnar and Oleg Nesterov for reviewing 
my initial patch series and giving me some pointers.


[1] www.wil.cx/matthew/lca2003/paper.pdf

-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 6/6] Convert tasklets to work queues

[Steven Rostedt]

This patch creates an alternative for drivers from using tasklets.
It creates a "work_tasklet". When configured to use work_tasklets
instead of tasklets, instead of creating tasklets, a work queue
is made in its place.  The API is still the same, and the drivers
don't know that a work queue is being used.

This is (for now) a proof of concept approach to using work queues
instead of tasklets.  More can be done. For one thing, we could make
individual work queues for each tasklet instead of using the global
ktasklet_wq.  But for now it's just easier to do this.

Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>


Index: linux-2.6-test/kernel/Kconfig.preempt
===
--- linux-2.6-test.orig/kernel/Kconfig.preempt
+++ linux-2.6-test/kernel/Kconfig.preempt
@@ -63,3 +63,18 @@ config PREEMPT_BKL
  Say Y here if you are building a kernel for a desktop system.
  Say N if you are unsure.
 
+config TASKLETS_AS_WORKQUEUES
+   bool "Treat tasklets as workqueues (EXPERIMENTAL)"
+   depends on EXPERIMENTAL
+   help
+ Tasklets are an old solution to an old problem with respect
+ to SMP.  But today they are not necessary anymore.
+ There are better solutions to the problem that tasklets
+ are trying to solve.
+
+ This option converts tasklets into workqueues and
+ removes the tasklet softirq.  This is a clean up until
+ we get rid of all tasklets that are currently in
+ the kernel.
+
+ Say Y if you are unsure and brave (not very well tested code!).
Index: linux-2.6-test/kernel/Makefile
===
--- linux-2.6-test.orig/kernel/Makefile
+++ linux-2.6-test/kernel/Makefile
@@ -21,7 +21,11 @@ obj-$(CONFIG_FUTEX) += futex.o
 ifeq ($(CONFIG_COMPAT),y)
 obj-$(CONFIG_FUTEX) += futex_compat.o
 endif
+ifeq ($(CONFIG_TASKLETS_AS_WORKQUEUES), y)
+obj-y += tasklet_work.o
+else
 obj-y += tasklet.o
+endif
 obj-$(CONFIG_RT_MUTEXES) += rtmutex.o
 obj-$(CONFIG_DEBUG_RT_MUTEXES) += rtmutex-debug.o
 obj-$(CONFIG_RT_MUTEX_TESTER) += rtmutex-tester.o
Index: linux-2.6-test/init/main.c
===
--- linux-2.6-test.orig/init/main.c
+++ linux-2.6-test/init/main.c
@@ -121,6 +121,11 @@ extern void time_init(void);
 /* Default late time init is NULL. archs can override this later. */
 void (*late_time_init)(void);
 extern void softirq_init(void);
+#ifdef CONFIG_TASKLETS_AS_WORKQUEUES
+  extern void init_tasklets(void);
+#else
+# define init_tasklets() do { } while(0)
+#endif
 
 /* Untouched command line saved by arch-specific code. */
 char __initdata boot_command_line[COMMAND_LINE_SIZE];
@@ -706,6 +711,7 @@ static void __init do_basic_setup(void)
 {
/* drivers will send hotplug events */
init_workqueues();
+   init_tasklets();
usermodehelper_init();
driver_init();
init_irq_proc();
Index: linux-2.6-test/include/linux/tasklet.h
===
--- linux-2.6-test.orig/include/linux/tasklet.h
+++ linux-2.6-test/include/linux/tasklet.h
@@ -1,6 +1,10 @@
 #ifndef _LINUX_TASKLET_H
 #define _LINUX_TASKLET_H
 
-#include 
+#ifdef CONFIG_TASKLETS_AS_WORKQUEUES
+# include 
+#else
+# include 
+#endif
 
 #endif
Index: linux-2.6-test/include/linux/tasklet_work.h
===
--- /dev/null
+++ linux-2.6-test/include/linux/tasklet_work.h
@@ -0,0 +1,62 @@
+#ifndef _LINUX_WORK_TASKLET_H
+#define _LINUX_WORK_TASKLET_H
+
+#ifndef _LINUX_INTERRUPT_H
+# error "Do not include this header directly! use linux/interrupt.h"
+#endif
+
+#include 
+
+extern void work_tasklet_exec(struct work_struct *work);
+
+struct tasklet_struct
+{
+   struct work_struct work;
+   struct list_head list;
+   unsigned long state;
+   atomic_t count;
+   void (*func)(unsigned long);
+   unsigned long data;
+   char *n;
+};
+
+#define DECLARE_TASKLET(name, func, data)  \
+   struct tasklet_struct name = {  \
+   __WORK_INITIALIZER((name).work, work_tasklet_exec), \
+   LIST_HEAD_INIT((name).list),\
+   0,  \
+   ATOMIC_INIT(0), \
+   func,   \
+   data,   \
+   #name   \
+   }
+
+#define DECLARE_TASKLET_DISABLED(name, func, data) \
+   struct tasklet_struct name = {  \
+   __WORK_INITIALIZER((name).work, work_tasklet_exec), \
+   LIST_HEAD_INIT((name).list),   

[RFC PATCH 3/6] Add a tasklet is-scheduled API

[Steven Rostedt]

This patch adds a tasklet_is_scheduled API to allow a driver
to know if its tasklet is already scheduled.

Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>

Index: linux-2.6-test/include/linux/tasklet.h
===
--- linux-2.6-test.orig/include/linux/tasklet.h
+++ linux-2.6-test/include/linux/tasklet.h
@@ -107,6 +107,11 @@ static inline void tasklet_hi_enable(str
atomic_dec(>count);
 }
 
+static inline int tasklet_is_scheduled(struct tasklet_struct *t)
+{
+   return test_bit(TASKLET_STATE_SCHED, >state);
+}
+
 extern void tasklet_kill(struct tasklet_struct *t);
 extern void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu);
 extern void tasklet_init(struct tasklet_struct *t,

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 5/6] Move tasklet.h to tasklet_softirq.h

[Steven Rostedt]

Getting ready for the two versions of tasklet implementations,
we move tasklet.h to tasklet_softirq.h and just include it in
tasklet.h.

Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>

Index: linux-2.6-test/include/linux/tasklet.h
===
--- linux-2.6-test.orig/include/linux/tasklet.h
+++ linux-2.6-test/include/linux/tasklet.h
@@ -1,125 +1,6 @@
 #ifndef _LINUX_TASKLET_H
 #define _LINUX_TASKLET_H
 
-/* Tasklets --- multithreaded analogue of BHs.
+#include 
 
-   Main feature differing them of generic softirqs: tasklet
-   is running only on one CPU simultaneously.
-
-   Main feature differing them of BHs: different tasklets
-   may be run simultaneously on different CPUs.
-
-   Properties:
-   * If tasklet_schedule() is called, then tasklet is guaranteed
- to be executed on some cpu at least once after this.
-   * If the tasklet is already scheduled, but its excecution is still not
- started, it will be executed only once.
-   * If this tasklet is already running on another CPU (or schedule is called
- from tasklet itself), it is rescheduled for later.
-   * Tasklet is strictly serialized wrt itself, but not
- wrt another tasklets. If client needs some intertask synchronization,
- he makes it with spinlocks.
- */
-
-struct tasklet_struct
-{
-   struct tasklet_struct *next;
-   unsigned long state;
-   atomic_t count;
-   void (*func)(unsigned long);
-   unsigned long data;
-};
-
-#define DECLARE_TASKLET(name, func, data) \
-struct tasklet_struct name = { NULL, 0, ATOMIC_INIT(0), func, data }
-
-#define DECLARE_TASKLET_DISABLED(name, func, data) \
-struct tasklet_struct name = { NULL, 0, ATOMIC_INIT(1), func, data }
-
-
-enum
-{
-   TASKLET_STATE_SCHED,/* Tasklet is scheduled for execution */
-   TASKLET_STATE_RUN   /* Tasklet is running (SMP only) */
-};
-
-#ifdef CONFIG_SMP
-static inline int tasklet_trylock(struct tasklet_struct *t)
-{
-   return !test_and_set_bit(TASKLET_STATE_RUN, &(t)->state);
-}
-
-static inline void tasklet_unlock(struct tasklet_struct *t)
-{
-   smp_mb__before_clear_bit(); 
-   clear_bit(TASKLET_STATE_RUN, &(t)->state);
-}
-
-static inline void tasklet_unlock_wait(struct tasklet_struct *t)
-{
-   while (test_bit(TASKLET_STATE_RUN, &(t)->state)) { barrier(); }
-}
-#else
-#define tasklet_trylock(t) 1
-#define tasklet_unlock_wait(t) do { } while (0)
-#define tasklet_unlock(t) do { } while (0)
 #endif
-
-extern void FASTCALL(__tasklet_schedule(struct tasklet_struct *t));
-
-static inline void tasklet_schedule(struct tasklet_struct *t)
-{
-   if (!test_and_set_bit(TASKLET_STATE_SCHED, >state))
-   __tasklet_schedule(t);
-}
-
-extern void FASTCALL(__tasklet_hi_schedule(struct tasklet_struct *t));
-
-static inline void tasklet_hi_schedule(struct tasklet_struct *t)
-{
-   if (!test_and_set_bit(TASKLET_STATE_SCHED, >state))
-   __tasklet_hi_schedule(t);
-}
-
-
-static inline void tasklet_disable_nosync(struct tasklet_struct *t)
-{
-   atomic_inc(>count);
-   smp_mb__after_atomic_inc();
-}
-
-static inline void tasklet_disable(struct tasklet_struct *t)
-{
-   tasklet_disable_nosync(t);
-   tasklet_unlock_wait(t);
-   smp_mb();
-}
-
-static inline void tasklet_enable(struct tasklet_struct *t)
-{
-   smp_mb__before_atomic_dec();
-   atomic_dec(>count);
-}
-
-static inline void tasklet_hi_enable(struct tasklet_struct *t)
-{
-   smp_mb__before_atomic_dec();
-   atomic_dec(>count);
-}
-
-static inline int tasklet_is_scheduled(struct tasklet_struct *t)
-{
-   return test_bit(TASKLET_STATE_SCHED, >state);
-}
-
-extern void tasklet_kill(struct tasklet_struct *t);
-extern void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu);
-extern void tasklet_init(struct tasklet_struct *t,
-void (*func)(unsigned long), unsigned long data);
-
-#ifdef CONFIG_HOTPLUG_CPU
-void takeover_tasklets(unsigned int cpu);
-#endif /* CONFIG_HOTPLUG_CPU */
-
-#endif /* _LINUX_TASKLET_H */
-
Index: linux-2.6-test/include/linux/tasklet_softirq.h
===
--- /dev/null
+++ linux-2.6-test/include/linux/tasklet_softirq.h
@@ -0,0 +1,129 @@
+#ifndef _LINUX_TASKLET_SOFTIRQ_H
+#define _LINUX_TASKLET_SOFTIRQ_H
+
+#ifndef _LINUX_TASKLET_H
+# error "Do not include this header directly! use linux/tasklet.h"
+#endif
+
+/* Tasklets --- multithreaded analogue of BHs.
+
+   Main feature differing them of generic softirqs: tasklet
+   is running only on one CPU simultaneously.
+
+   Main feature differing them of BHs: different tasklets
+   may be run simultaneously on different CPUs.
+
+   Properties:
+   * If tasklet_schedule() is called, then tasklet is guaranteed
+ to be executed on some cpu at least once after this.
+   * If the tasklet is already scheduled, but its excecution is still not
+ started, it will be executed only 

[RFC PATCH 2/6] Split out tasklets from softirq.c

[Steven Rostedt]

Tasklets are really a separate entity from softirqs, so they
deserve their own file. Also this allows us to easily replace
tasklets for something else ;-)

Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>

Index: linux-2.6-test/include/linux/interrupt.h
===
--- linux-2.6-test.orig/include/linux/interrupt.h
+++ linux-2.6-test/include/linux/interrupt.h
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -268,117 +269,6 @@ extern void FASTCALL(raise_softirq_irqof
 extern void FASTCALL(raise_softirq(unsigned int nr));
 
 
-/* Tasklets --- multithreaded analogue of BHs.
-
-   Main feature differing them of generic softirqs: tasklet
-   is running only on one CPU simultaneously.
-
-   Main feature differing them of BHs: different tasklets
-   may be run simultaneously on different CPUs.
-
-   Properties:
-   * If tasklet_schedule() is called, then tasklet is guaranteed
- to be executed on some cpu at least once after this.
-   * If the tasklet is already scheduled, but its excecution is still not
- started, it will be executed only once.
-   * If this tasklet is already running on another CPU (or schedule is called
- from tasklet itself), it is rescheduled for later.
-   * Tasklet is strictly serialized wrt itself, but not
- wrt another tasklets. If client needs some intertask synchronization,
- he makes it with spinlocks.
- */
-
-struct tasklet_struct
-{
-   struct tasklet_struct *next;
-   unsigned long state;
-   atomic_t count;
-   void (*func)(unsigned long);
-   unsigned long data;
-};
-
-#define DECLARE_TASKLET(name, func, data) \
-struct tasklet_struct name = { NULL, 0, ATOMIC_INIT(0), func, data }
-
-#define DECLARE_TASKLET_DISABLED(name, func, data) \
-struct tasklet_struct name = { NULL, 0, ATOMIC_INIT(1), func, data }
-
-
-enum
-{
-   TASKLET_STATE_SCHED,/* Tasklet is scheduled for execution */
-   TASKLET_STATE_RUN   /* Tasklet is running (SMP only) */
-};
-
-#ifdef CONFIG_SMP
-static inline int tasklet_trylock(struct tasklet_struct *t)
-{
-   return !test_and_set_bit(TASKLET_STATE_RUN, &(t)->state);
-}
-
-static inline void tasklet_unlock(struct tasklet_struct *t)
-{
-   smp_mb__before_clear_bit(); 
-   clear_bit(TASKLET_STATE_RUN, &(t)->state);
-}
-
-static inline void tasklet_unlock_wait(struct tasklet_struct *t)
-{
-   while (test_bit(TASKLET_STATE_RUN, &(t)->state)) { barrier(); }
-}
-#else
-#define tasklet_trylock(t) 1
-#define tasklet_unlock_wait(t) do { } while (0)
-#define tasklet_unlock(t) do { } while (0)
-#endif
-
-extern void FASTCALL(__tasklet_schedule(struct tasklet_struct *t));
-
-static inline void tasklet_schedule(struct tasklet_struct *t)
-{
-   if (!test_and_set_bit(TASKLET_STATE_SCHED, >state))
-   __tasklet_schedule(t);
-}
-
-extern void FASTCALL(__tasklet_hi_schedule(struct tasklet_struct *t));
-
-static inline void tasklet_hi_schedule(struct tasklet_struct *t)
-{
-   if (!test_and_set_bit(TASKLET_STATE_SCHED, >state))
-   __tasklet_hi_schedule(t);
-}
-
-
-static inline void tasklet_disable_nosync(struct tasklet_struct *t)
-{
-   atomic_inc(>count);
-   smp_mb__after_atomic_inc();
-}
-
-static inline void tasklet_disable(struct tasklet_struct *t)
-{
-   tasklet_disable_nosync(t);
-   tasklet_unlock_wait(t);
-   smp_mb();
-}
-
-static inline void tasklet_enable(struct tasklet_struct *t)
-{
-   smp_mb__before_atomic_dec();
-   atomic_dec(>count);
-}
-
-static inline void tasklet_hi_enable(struct tasklet_struct *t)
-{
-   smp_mb__before_atomic_dec();
-   atomic_dec(>count);
-}
-
-extern void tasklet_kill(struct tasklet_struct *t);
-extern void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu);
-extern void tasklet_init(struct tasklet_struct *t,
-void (*func)(unsigned long), unsigned long data);
-
 /*
  * Autoprobing for irqs:
  *
Index: linux-2.6-test/include/linux/tasklet.h
===
--- /dev/null
+++ linux-2.6-test/include/linux/tasklet.h
@@ -0,0 +1,120 @@
+#ifndef _LINUX_TASKLET_H
+#define _LINUX_TASKLET_H
+
+/* Tasklets --- multithreaded analogue of BHs.
+
+   Main feature differing them of generic softirqs: tasklet
+   is running only on one CPU simultaneously.
+
+   Main feature differing them of BHs: different tasklets
+   may be run simultaneously on different CPUs.
+
+   Properties:
+   * If tasklet_schedule() is called, then tasklet is guaranteed
+ to be executed on some cpu at least once after this.
+   * If the tasklet is already scheduled, but its excecution is still not
+ started, it will be executed only once.
+   * If this tasklet is already running on another CPU (or schedule is called
+ from tasklet itself), it is rescheduled for later.
+   * Tasklet is strictly serialized wrt itself, but not
+ wrt 

RE: [PATCH] Chinese translation of Documentation/HOWTO

[Li Yang-r58472]

> -Original Message-
> From: Rob Landley [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 22, 2007 10:49 AM
> 
> On Thursday 21 June 2007 10:40:17 Li Yang wrote:
> > This is a Chinese translated version of Documentation/HOWTO.
Currently
> > Chinese involvement in Linux kernel is very low, especially
comparing to
> > its largest population base.  Language could be the main obstacle.
Hope
> > this document will help more Chinese to contribute to Linux kernel.
> 
> I'm putting together a kernel documentation directory at
http://kernel.org/doc
> and I could easily add translations in there.  I just don't know if
this is a
> good idea.
> 
> The problem is, the submission of patches happens on the various
kernel.org
> mailing lists, which are all in English.  Kernel development is done
in a
> single common language: English.  (If you'd like to argue for it to be
done
> in another language, please make the proposal in Linus's native
Swedish.)
> 
> Setting aside for the moment version skew and coverage issues when
translating
> Documentation, which aren't really serious blocking issues, my
question is
> this:  If developers aren't fluent enough with English to follow the
> documentation, how can they follow any of the technical discussions
necessary
> to merge their patches back into the mainstream kernel?  Doesn't this
> encourage the creation of patches that can't easily be merged back
into the
> kernel?

So as I argued in a previous email, non-native English speakers tend to
be more confused by the policies and processes.  I also don't think it's
necessary to translate the technical documents.  To be a software
developer, one has to be educated or experienced in technical terms.
Technical discussion can be done without too much requirement to grammar
and emotional expressing.  The translated document of policies and
processes will help these people to understand the process better and go
smoother in the process.

- Leo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Please release a stable kernel Linux 3.0

[Rik van Riel]

Zoltán HUBERT wrote:

So I feel that a turning-point is coming where a really 
really really (x 15) stable and reliable kernel is NEEDED.


You are free to create one, or follow Adrian Bunk's 2.6.16.x
series.  Nobody's stopping you.

Oh, 2.6.16 does not have the features you need?

You'd be out of luck with a stable/unstable kernel split,
since your stable kernel would not have the features...

--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Joshua Brindle]

[EMAIL PROTECTED] wrote:

On Thu, 21 Jun 2007, Joshua Brindle wrote:


Lars Marowsky-Bree wrote:

 On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
 


>  Um, no.  It might not be able to directly open files via that 
path, but
>  showing that it can never read or write your mail is a rather 
different

>  matter.
>
 Yes. Your use case is different than mine.



So.. your use case is what? If an AA user asked you to protect his 
mail from his browser I'm sure you'd truthfully answer "no, we can't 
do that but we can protect the path to your mail from your browser".. 
I think not. One need only look at the wonderful marketing literature 
for AA to see what you are telling people it can do, and your above 
statement isn't consistent with that, sorry.


remember, the policies define a white-list



Except for unconfined processes.

so if a hacker wants to have mozilla access the mail files he needs to 
get some other process on the sysstem to create a link or move a file 
to a path that mozilla does have access to. until that is done there 
is no way for mozilla to access the mail through the filesystem.


other programs could be run that would give mozilla access to the mail 
contents, but it would be through some other path that the policy 
permitted mozilla accessing in the first place.


Or through IPC or the network, that is the point, filesystem only 
coverage doesn't cut it; there is no way to say the browser can't access 
the users mail in AA, and there never will be.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC: 2.6 patch] schedule BLK_DEV_IDE_SATA for removal

[David Woodhouse]

On Fri, 2007-06-22 at 11:39 +0800, David Woodhouse wrote:
> On Fri, 2007-06-22 at 01:52 +0200, Adrian Bunk wrote:
> > Users should use the libata based drivers for SATA drives.
> 
> NAK. Not all IDE drivers are converted yet. Not even all the relatively
> common ones.

Ignore me. I thought you were trying to deprecate BLK_DEV_IDE. Sorry.

/me wanders off in search of more caffeine

-- 
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC: 2.6 patch] schedule BLK_DEV_IDE_SATA for removal

[David Woodhouse]

On Fri, 2007-06-22 at 01:52 +0200, Adrian Bunk wrote:
> Users should use the libata based drivers for SATA drives.

NAK. Not all IDE drivers are converted yet. Not even all the relatively
common ones.

-- 
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Kernel include files

[David Woodhouse]

On Fri, 2007-06-22 at 01:38 +0200, Joerg Schilling wrote:
> The main problems are not really hard to fix..
> 
> - Most problems eem to be related to the fact that Linux does not
>   use C-99 based types in the kernel and the related type definitions 
>   are not written in plain C. This is something that should be fixed
>   with a source consolidation program or by defining aliases to 
>   C-99 types in case the compiler is not GCC.


The argument has been made that the standard C99 types are _optional_,
and anything included from a C library's headers without _explicitly_
being included by the user shouldn't define those types.

Personally, I think that's a load of bollocks. And it certainly doesn't
apply to Linux-specific files like , which are perfectly
entitled to use a C standard from last millennium, regardless of
namespace 'pollution' issues. That's why we continue to use the crappy
__u32 types. Can you be more specific about why this is a problem? Don't
we mostly define those crappy types using arch-specific knowledge, as
'int', 'long', etc?

> - Other problems are caused by additional tag definitions that could
>   be disabled in case of a non-GCC compile.

We mostly try to remove this from user-visible parts of exported
headers. Sometimes we just remove it altogether; other bits are stripped
at export time when you run 'make headers_install'. Again, can you be
more specific about the problem?

-- 
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Chinese translation of Documentation/HOWTO

[dave young]

Hi,
2007/6/22, Rob Landley <[EMAIL PROTECTED]>:

On Thursday 21 June 2007 10:40:17 Li Yang wrote:
> This is a Chinese translated version of Documentation/HOWTO.  Currently
> Chinese involvement in Linux kernel is very low, especially comparing to
> its largest population base.  Language could be the main obstacle.  Hope
> this document will help more Chinese to contribute to Linux kernel.

I'm putting together a kernel documentation directory at http://kernel.org/doc
and I could easily add translations in there.  I just don't know if this is a
good idea.



I think it's not a good idea to merge translations into kernel.


The problem is, the submission of patches happens on the various kernel.org
mailing lists, which are all in English.  Kernel development is done in a
single common language: English.  (If you'd like to argue for it to be done
in another language, please make the proposal in Linus's native Swedish.)



Yes, I agree with you, and there's so many other languages, It's
better for someone to  create a standalone kdoc translation project
than to merge them into kernel.

Regards
dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Kyle Moffett]

On Jun 21, 2007, at 15:19:35, Stephen Clark wrote:

David Schwartz wrote:
On Wed, 20 Jun 2007 12:55:10 -0700 "David Schwartz"  
<[EMAIL PROTECTED]> wrote:
A key is a number. A signature is a number. They are neither  
statements nor instructions. The argument that GPLv2 prohibits  
Tivoization is really and truly absurd. It has neither a legal  
nor a moral leg to stand on.


A computer program is a number too.


No, it's not. It can be expressed as a number, but it is not a  
number.


??? can be expressed as a number, but it is not a number ??? sure  
its a number.


Keys are purely numbers, they are nothing else. Signatures are  
pure primitive facts encoded as numbers (authority X blessed  
object Y).


A computer program is a set of instructions to accomplish a  
particular result. It can be expressed as a number, but that  
doesn't mean it is a number.


It might be true in principle to develop a scheme whereby every  
physical object uniquely corresponds to an extremely large number.  
That doesn't turn physical objects into numbers.


Both of you lose this argument.  All irrational numbers, for example,  
"break" every copyright that could possibly exist.  For example, you  
can find any arbitrary sequence of Base-N digits when you express PI  
in base-N form.  I can simultaneously express both the laws of  
physics (not copyrightable) and the latest episode of the TV show  
"Numbers" (thoroughly copyrighted) as numbers.  In fact, we do both  
all the time (you can express both the latest equations for  
theoretical physics and a TV show as bits (IE: numbers) on an HDD.   
Ergo "$FOO is a number" says *NOTHING* about whether or not copyright  
applies to $FOO.  In case you haven't noticed, the whole damn point  
of math is that you can express *EVERYTHING* as numbers, albeit maybe  
horribly unbelievably complex ones.


Now, back to actual legal issues: Since most copyright laws  
explicitly prevent copyrighting of pure math, the only actual  
protection you have for some collection of so-called numbers is  
whether or not the numbers *REPRESENT* something which may be  
copyrighted.  Furthermore, copyright has _always_ been independent of  
representation; a person owns copyright on a book regardless of  
whether it's hardback, softcover, digital, memorized, etc.  The  
person who owns the copyright on a book is able to prevent someone  
who has memorized the book from giving public recitals of said book,  
and the neuron-linkage-based storage the brain uses is about as far  
as you can possibly get from twiddling magnetic bits on a disk drive  
or dumping carbon-based inks on a page made of plant cellulose.


Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Chinese translation of Documentation/HOWTO

[Rob Landley]

On Thursday 21 June 2007 10:40:17 Li Yang wrote:
> This is a Chinese translated version of Documentation/HOWTO.  Currently
> Chinese involvement in Linux kernel is very low, especially comparing to
> its largest population base.  Language could be the main obstacle.  Hope
> this document will help more Chinese to contribute to Linux kernel.

I'm putting together a kernel documentation directory at http://kernel.org/doc 
and I could easily add translations in there.  I just don't know if this is a 
good idea.

The problem is, the submission of patches happens on the various kernel.org 
mailing lists, which are all in English.  Kernel development is done in a 
single common language: English.  (If you'd like to argue for it to be done 
in another language, please make the proposal in Linus's native Swedish.)

Setting aside for the moment version skew and coverage issues when translating  
Documentation, which aren't really serious blocking issues, my question is 
this:  If developers aren't fluent enough with English to follow the 
documentation, how can they follow any of the technical discussions necessary 
to merge their patches back into the mainstream kernel?  Doesn't this 
encourage the creation of patches that can't easily be merged back into the 
kernel?

It could be that the answer is "no, it's fine".  I don't feel qualified to 
make this decision.  It's very easy for me to accept contributed translations 
and put them up, but I'd like some kind of consensus from the kernel 
developers that I SHOULD do this.  How much use is a Chinese version of a 
HOWTO that tells people how to interact with an English community?

Could somebody more qualified than me speak up on this one so I know what to 
do?

Rob

P.S.  I meant to comment when this topic first came up last week 
[http://kerneltrap.org/node/8365] but my laptop's hard drive died and I lost 
the link.  (Along with any chance of this being a particularly productive 
month for me...)

-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: utrace comments

[Roland McGrath]

Hi Russell.  Your last comments in this thread gave the impression you
thought that ARM's existing PTRACE_SINGLESTEP support would be lost by
converting to the utrace-based ptrace implementation.  Christoph Hellwig
posted a reply giving the (correct) details of how this is not the case.
But I gather there is still some misunderstanding circulating on this point.

Here is the section from utrace-arch-porting-howto.txt about this:

7. Software single-step.

   A few machines do not have any hardware single-step support, but provide
   PTRACE_SINGLESTEP by doing memory breakpoint insertion.  If your machine
   does this, do not define tracehook_enable_single_step et al.  The
   tracehook single-step/block-step functions are intended for true
   hardware support, or forms of software support that truly work as well
   as hardware support does.  Simply changing memory has a lot of problems,
   notably its incompatibility with multi-threaded debugging.

   For ptrace compatibility, just handle PTRACE_SINGLESTEP in your
   arch_ptrace function using your existing code.  If arch_ptrace needs
   to do something that should be undone when ptrace cleans up,
   asm/ptrace.h can #define HAVE_ARCH_PTRACE_DETACH and it will
   call void arch_ptrace_detach(struct task_struct *) before detaching.

   In future, the utrace world will have facilities to do things like
   per-thread breakpoints while mitigating the bad side effects of
   breakpoint insertion.  Then single-stepping will be emulated using
   those.  Until we have that, your old PTRACE_SINGLESTEP support code is
   fine for ptrace, but new utrace-based users will expect not to see side
   effects like memory-writing breakpoint insertion and are better off not
   falsely thinking there is proper single-step support.

I think that is pretty unambiguous, but please advise me how to make it
more clear.  In short, any existing arch with PTRACE_SINGLESTEP support
will keep it.  What differs between an arch with hardware support and an
arch doing a breakpoint-insertion hack is just where the old code is moved
to in the newly reorganized code.  Hardware support (or anything
indistinguishable from it) goes in tracehook_enable_single_step et al.
Old-style memory-modifying breakpoint-insertion goes into arch_ptrace.

> I have no real problem with a decision being made to drop kernel-based
> single stepping _provided_ we have some replacement strategy in place
> and readily available.  At the moment I've not seen such a strategy.

I never intended to suggest in any way that any regression in the behavior
of the ptrace call on any machine would be acceptable.  Maintaining the
status quo for ptrace is straightforward.

The challenge for machines without hardware single-step support is for the
future, more-interesting things built on utrace, unrelated to ptrace, to
support instruction-step features in nice ways.  I have not gotten into
details of the strategies for that because it is still vaporware barely
tried yet even in contorted prototype forms, and is not directly apropos to
the more immediate goal of integrating the utrace core into the kernel
without regressions in ptrace behavior.

> I'm not sure if Roland's expecting architecture maintainers to
> create such a strategy themselves - which would probably turn out to
> being far worse since you could end up with different implementations
> for each architecture.

Indeed I do not expect any arch to start from scratch, just to do the
narrowly arch-specific parts.  There isn't even a prototype of something to
try doing new ports of, so I have not mentioned details of what arch
support entails.  Making kprobes work robustly for your arch is useful
related work that you can do now (and someone has done some for ARM), not
that it addresses the userland single-step issue per se, but the arch
implementation details for kprobes inform arch details of some strategies
available.  We can talk about it if you like, but that is future work for
new features beyond the status quo.  I wouldn't like to conflate it with
discussions about the utrace work that exists now, or let that slow down
review or arch ports for the basic infrastructure.


I hope you will consider taking another crack at the utrace port for your
arch.  It really is not so much work.  If your arch is supported well by
qemu, and you can point me to either a qemu disk image or an easily
installed distro version that works well for kernel hacking on your arch, I
would be happy to give it a whirl to help write and debug the port.



Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] serial: Clear proper MPSC interrupt cause bits

[Mark A. Greer]

From: Jay Lubomirski <[EMAIL PROTECTED]>

Don't clobber the interrupt cause bits for both MPSC controllers when
clearing the interrupt for one of them.  Just clear the one that is
supposed to be cleared.

Signed-off-by: Jay Lubomirski <[EMAIL PROTECTED]>
Acked-by: Mark A. Greer <[EMAIL PROTECTED]>
---
 drivers/serial/mpsc.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/serial/mpsc.c b/drivers/serial/mpsc.c
index d09f209..00924fe 100644
--- a/drivers/serial/mpsc.c
+++ b/drivers/serial/mpsc.c
@@ -503,7 +503,8 @@ mpsc_sdma_intr_ack(struct mpsc_port_info *pi)
 
if (pi->mirror_regs)
pi->shared_regs->SDMA_INTR_CAUSE_m = 0;
-   writel(0, pi->shared_regs->sdma_intr_base + SDMA_INTR_CAUSE);
+   writeb(0x00, pi->shared_regs->sdma_intr_base + SDMA_INTR_CAUSE +
+  pi->port.line);
return;
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: limits on raid

[Neil Brown]

On Thursday June 21, [EMAIL PROTECTED] wrote:
> I didn't get a comment on my suggestion for a quick and dirty fix for 
> -assume-clean issues...
> 
> Bill Davidsen wrote:
> > How about a simple solution which would get an array on line and still 
> > be safe? All it would take is a flag which forced reconstruct writes 
> > for RAID-5. You could set it with an option, or automatically if 
> > someone puts --assume-clean with --create, leave it in the superblock 
> > until the first "repair" runs to completion. And for repair you could 
> > make some assumptions about bad parity not being caused by error but 
> > just unwritten.

It is certainly possible, and probably not a lot of effort.  I'm not
really excited about it though.

So if someone to submit a patch that did the right stuff,  I would
probably accept it, but I am unlikely to do it myself.


> >
> > Thought 2: I think the unwritten bit is easier than you think, you 
> > only need it on parity blocks for RAID5, not on data blocks. When a 
> > write is done, if the bit is set do a reconstruct, write the parity 
> > block, and clear the bit. Keeping a bit per data block is madness, and 
> > appears to be unnecessary as well.

Where do you propose storing those bits?  And how many would you cache
in memory?  And what performance hit would you suffer for accessing
them?  And would it be worth it?

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[David Schwartz]

On Jun 21, 2007, [EMAIL PROTECTED] wrote:

> On Jun 21, 2007, [EMAIL PROTECTED] wrote:

> >> For the record, GPLv2 is already meant to accomplish this.  I don't
> >> understand why people who disagree with this stance chose GPLv2.
> >> Isn't "no further restrictions" clear enough?

> > everyone else is reading this as 'no further license restrictions'

> I didn't see anyone else add "license" where you did.  "No further
> restrictions on the rights granted herein" is very powerful and
> extensive, and that's how it was meant to be.

I agree. For example, a patent might impose a further restriction. The GPL
was clearly meant to foreclose that. There are any number of other ways of
nasty, subtle ways to impose further restrictions, and the GPLv2 meant to
foreclose all of them.

> > not no hardware restrictions' becouse GPLv2 explicitly says that it
> > has nothing to do with running the software, only with distributing
> > it.

> It also says that running the software is not restricted, and since
> copyright law in the US doesn't regulate execution, receiving the
> software does grant the recipient the right to run the software.  So
> the distributor can't impose restrictions on it.

Right.

The response to this argument is that it is mind-bogglingly obvious that the
GPL doesn't mean that no *authorization* decisions can stand in your way. It
didn't mean that I couldn't keep the root password to my server secret even
though that denies you the "right" to modify the Linux kernel running on it.

Some entity has to decide what software runs on any particular piece of
hardware, and it was never the intent of the GPL to specify or limit who
that person was. This has been discussed many times over many years, longer
before Tivoization was even thought of, and it was agreed that the GPL
didn't foreclose authorization obstacles to software modification.

Why doesn't Linux allow a non-root user to install a module or change which
kernel the system runs? Doesn't that limit the GPL rights of all non-root
users to modify the GPL'd kernel software on that machine? OF COURSE NOT.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Bron Gondwana]

On Thu, Jun 21, 2007 at 06:39:07AM -0300, Alexandre Oliva wrote:
> If GPLv3 were to have a clause that permitted combination/linking with
> code under GPLv2, this wouldn't be enough for GPLv3 projects to use
> Linux code, and it wouldn't be enough for Linux code to use GPLv3
> projects.  That's because GPLv2 would still demand all code to be
> licensed under GPLv2, and GPLv3 wouldn't permit this.
> 
> However, if GPLv3 had a permission to combine/link with code under
> GPLv2, *and* Linux (and any other projects interested in mutual
> compatibility) introduced an additional permission to combine/link
> with code under GPLv3 (or even GPLv3+, constrained by some condition
> if you will), then:

My god, you really have come totally unhinged in your attempt to
reconcile two incompatible ideas.  Ouch.

The reason the GPLv2 ecosystem is so strong is that you can take any
code under GPLv2 and combine it with any other code under GPLv2 and the
result is GPLv2.  All you have to check is that the original code is
either GPLv2 or a licence that allows conversion to GPLv2, that's it.

None of this "Projects" nonsense.

Who says what code is a "project" and if it has any special
relationships with other "projects" that allow code sharing above and
beyond their standard licence terms.  Suddenly using other GPLv2 code
becomes fraught with "which path did I obtain this licence down" games
and either a big fat pile of paperwork or plain not being able to be
clear about the licencing of of the code.

It's not about projects, it's about the code.  Gah.  You're not going
to make a happy, happy merging code sharing world by fragmenting the
licence landscape even more.

Bron.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Bron Gondwana]

On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
> 
> >> > Wouldn't that defeat the entire purpose of the GPLv3? Couldn't
> >> > I take any
> >> > GPLv3 program, combine it with a few lines of Linux code, and
> >> > Tivoize the
> >> > result?
> 
> >> No.  This is not permission to relicense.  This is permission to
> >> combine.  Each author still gets to enforce the terms of her own code.
> 
> > This makes no sense. We are not talking mere aggregation here, we are
> > talking developmental convergence. If I wrote some code that was in the
> > Linux kernel, how can I enforce the terms of my code (guaranteed write to
> > Tivoize) in the derivative work that it becomes mixed with?
> 
> In just the same way you'd enforce it today: with help from a lawyer
> who understands these issues that you clearly don't understand.

Great, so for ever and ever afterwards the code would have to keep a
clear separation between the bits that are under different licences and
make sure that no re-factor ever blurred the lines between them enough
that you had trouble telling which was which.

And don't even get me started about some poor innocent end-user who just
wants to use some code from your mutant frankenstein "project" in her
pong game (or was it tetris, I lose track of what you're supposed to be
playing on your hacked TiVo while it's not allowed to connect to their
network any more) and understand what licence the final work is under.

Ouch.

Bron.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] driver core: multithreaded probing - more parallelism control

[Huang, Ying]

On Thu, 2007-06-21 at 18:21 +0200, Stefan Richter wrote:
> Parallelism between subsystems may be interesting during boot ==
> "coldplug", /if/ the machine has time-consuming devices to probe on
> /different/ types of buses.  Of course some machines do the really
> time-consuming stuff on only one type of bus.  Granted, parallelism
> betwen subsystems is not very interesting anymore later after boot ==
> "hotplug".

Yes. So I think there are two possible solution.

1. Creating one set of probing queues for each subsystem (maybe just the
subsystems need it), so the probing queue IDs are local to each
subsystem.
2. There is only one set of probing queues in whole system. The probing
queue IDs are shared between subsystems. The subsystem can select a
random starting queue ID (maybe named as start_queue_id), and allocate
the queue IDs from that point on (start_queue_id + private_queue_id). So
the probability of queue ID sharing will be reduced.

> (The old FireWire stack will re-enter the main loop of the bus scanning
> thread sometime after a bus reset event signaled that nodes or units may
> have appeared or disappeared.  The new FireWire stack will schedule
> respective scanning workqueue jobs after such an event.)

I think the workqueue is better than kernel thread here. With kernel
thread, the nodes and units may be needed to be scanned again and again
for each unit/node if many units/nodes are appeared at almost the same
time, while with workqueue, just schedule the jobs needed.

And a workqueue like the probing queue whose thread can be
created/destroyed on demand will save more resources than ordinary
workqueue. :)

Best Regards,
Huang Ying
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: TUX2 filesystem

[Bron Gondwana]

On Thu, Jun 21, 2007 at 03:26:15PM -0700, Zach Brown wrote:
> > Second, Oracle is now working on Btrfs (if ever a FS needed a better 
> > name... is that pronounced ButterFS?).
> 
> (In our silliest moments, yes.  Absolutely.)

I'm sure when the PHBen are around it's "Better FS".

It's all a Free(software)Mason conspiracy, I tell you.

Bron.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NUMA BOF @OLS

[Christoph Lameter]

On Fri, 22 Jun 2007, Arnd Bergmann wrote:

> - Interface for preallocating hugetlbfs pages per node instead of system wide

We may want to get a bit higher level than that. General way of 
controlling subsystem use on nodes. One wants to restrict the slab 
allocator and the kernel etc on nodes too.

How will this interact with the other NUMA policy specifications?
 
> - architecture independent in-kernel API for enumerating CPU sockets with
>   multicore processors (not sure if that's the same as your existing subject).

Not sure what you mean by this. We already have a topology interface and 
the scheduler knows about these things.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how to tell linux (on x86) to ignore 1M or memory

[H. Peter Anvin]

Rene Herman wrote:
> On 04/19/2007 04:18 PM, Bart Trojanowski wrote:
> 
>> I need to preserve some state from the bios before entering protected
>> mode.  For now I want to copy it into some ram accessible by
>> real-mode, say the last megabyte visible in real-mode.
>>
>> What's the easiest way to have linux ignore the megabyte starting at 15M?
> 
> Note that real-mode can only access the first megabyte (*) and not the
> first 16. 16MB is the 16-bit protected mode (286) limit.
> 

No, 16-bit protected mode (on 386+) is not limited to 16 MB.

The main reason there is a 16 MB limit in some current systems is that
ISA, and the ISA DMA controller only had 24 address lines.

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in a driver while using SLUB as a SLAB allocator

[Christoph Lameter]

On Thu, 21 Jun 2007, Hugh Dickins wrote:

> Seems a little odd that it's gone throughout 2.6.22-rc unnoticed
> until now - nobody else trying SLUB on ARM or PA-RISC yet perhaps.

The impact is only on a subset of ARM machines.

PA_RISC? It looks like they run their own flushing function for byte 
ranges called flush_kernel_dache_range. That does not use the page struct.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in a driver while using SLUB as a SLAB allocator

[Christoph Lameter]

Maybe this will address the issue on ARM?


ARM: Allocate dma pages via the page allocator and not via the slab allocator

Slab allocations are not guaranteed to be page aligned and slab allocators
may use the page structs for their own purposes. Using the page allocator
yields a properly aligned page and also makes the page flushing logic work 
right.

Passing a kmalloced "page" to a flushing function will not work reliably.

This will hopefully address the issue with SLUB on ARM. SLUB uses the
page->mapping field which is also checked by the flushing logic. The
flushing logic expects a normal page and not a slab page.

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>

---
 arch/arm/mm/consistent.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6/arch/arm/mm/consistent.c
===
--- linux-2.6.orig/arch/arm/mm/consistent.c 2007-06-21 18:18:15.0 
-0700
+++ linux-2.6/arch/arm/mm/consistent.c  2007-06-21 18:29:16.0 -0700
@@ -277,7 +277,7 @@ dma_alloc_coherent(struct device *dev, s
if (arch_is_coherent()) {
void *virt;
 
-   virt = kmalloc(size, gfp);
+   virt = get_free_pages(gfp, get_order(size));
if (!virt)
return NULL;
*handle =  virt_to_dma(dev, virt);
@@ -364,7 +364,7 @@ void dma_free_coherent(struct device *de
WARN_ON(irqs_disabled());
 
if (arch_is_coherent()) {
-   kfree(cpu_addr);
+   free_pages((unsigned long)cpu_addr, get_order(size));
return;
}
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Al Viro]

On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote:

> Do you agree that if there's any single contributor who thinks it
> can't be tivoized, and he manages his opinion to prevail in court
> against a copyright holder, then it can't?  That this is the same
> privilege to veto additional permissions that Al Viro has just
> claimed?

You know, I'm rapidly losing any respect for your integrity.  The only
"privelege" claimed is that of not relicensing one's contributions.
_You_ are perfectly welcome to allow distribution of your code under
whatever license you happen to like.  So is anybody else (provided that
they separate their code from that of other contributors).  I cannot
do that to your code.  Neither can Linus.

If Alan sues some company for doing things violating in his opinion his
copyright on some of his code *and* wins it, then it's likely to simplify
later cases of that kind, provided that situation is similar enough to
make the legal arguments used in the first case apply in the later one.

If Joe Random Wanker takes your code (in gcc, kernel, whatever) and starts
distributing it in violation of conditions set in your copyright *and*
you sue him *and* win (which is bloody likely), then further cases of that
kind get somewhat easier to win.  Not much, actually, since there's already
a whole lot of precedents already.

What really gets me is that you know it.  And you know that just about
everyone here knows it.  Yet you keep playing with rather pathetic
attempts of innuendo and misdirection, when it's bloody obvious that
you won't even get a PR win out of the entire mess you've been sustaining
for about a week already (seriously, count postings in these threads).

The first law of holes: when you are in one, stop digging...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 21, 2007, [EMAIL PROTECTED] wrote:

> On Thu, 21 Jun 2007, Alexandre Oliva wrote:
>> On Jun 21, 2007, [EMAIL PROTECTED] wrote:
>> 
>>> this is your right with your code. please stop browbeating people who
>>> disagree with you.
>> 
>> For the record, GPLv2 is already meant to accomplish this.  I don't
>> understand why people who disagree with this stance chose GPLv2.
>> Isn't "no further restrictions" clear enough?

> everyone else is reading this as 'no further license restrictions'

I didn't see anyone else add "license" where you did.  "No further
restrictions on the rights granted herein" is very powerful and
extensive, and that's how it was meant to be.

> not no hardware restrictions' becouse GPLv2 explicitly says that it
> has nothing to do with running the software, only with distributing
> it.

It also says that running the software is not restricted, and since
copyright law in the US doesn't regulate execution, receiving the
software does grant the recipient the right to run the software.  So
the distributor can't impose restrictions on it.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Thu, 21 Jun 2007, Chris Mason wrote:

> > The incomplete mediation flows from the design, since the pathname-based
> > mediation doesn't generalize to cover all objects unlike label- or
> > attribute-based mediation.  And the "use the natural abstraction for
> > each object type" approach likewise doesn't yield any general model or
> > anything that you can analyze systematically for data flow.
> 
> This feels quite a lot like a repeat of the discussion at the kernel
> summit.  There are valid uses for path based security, and if they don't
> fit your needs, please don't use them.  But, path based semantics alone
> are not a valid reason to shut out AA.

The validity or otherwise of pathname access control is not being 
discussed here.

The point is that the pathname model does not generalize, and that 
AppArmor's inability to provide adequate coverage of the system is a 
design issue arising from this.

Recall that the question asked by Lars was whether there were any 
outstanding technical issues relating to AppArmor.

AppArmor does not and can not provide the level of confinement claimed by 
the documentation, and its policy does not reflect its actual confinement 
properties.  That's kind of a technical issue, right?


- James
-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in a driver while using SLUB as a SLAB allocator

[Christoph Lameter]

On Thu, 21 Jun 2007, Hugh Dickins wrote:

> > The oops seems to occur after a page unmapping using dma_unmap_page() 
> > followed
> > by a flush_dcache_page() (in at91mci_post_dma_read()).

Was the page allocated using slab calls?

> Seems a little odd that it's gone throughout 2.6.22-rc unnoticed
> until now - nobody else trying SLUB on ARM or PA-RISC yet perhaps.
> As I understand it, you're not doing anything wrong (disclaimer:
> I'm no expert on dma_mapping things), but SLUB's reuse of struct
> page fields has collided with what flush_dcache_page is expecting.
> 
> Here's a patch: I'm not convinced it's necessarily the best one
> (most uses of page_mapping will never see a slab page, it's a pity
> to be cluttering up that inline even further); but in case nobody
> else can provide a better...

Well one may be better off allocating pages using the page allocator 
instead of the slab allocator. I removed these things from i386 but I did 
not check ARM.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

> It's this simple, those who chose the GPLv2 for Linux and their
> contributions to it don't want people to create derivative works of their
> works that can't be Tivoized.

Do you agree that if there's any single contributor who thinks it
can't be tivoized, and he manages his opinion to prevail in court
against a copyright holder, then it can't?  That this is the same
privilege to veto additional permissions that Al Viro has just
claimed?

http://lkml.org/lkml/2007/6/13/293
http://lkml.org/lkml/2007/6/13/354
http://lkml.org/lkml/2007/6/14/117
http://lkml.org/lkml/2007/6/14/432

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Jan Harkes]

On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
> 
> >> > Wouldn't that defeat the entire purpose of the GPLv3? Couldn't
> >> > I take any
> >> > GPLv3 program, combine it with a few lines of Linux code, and
> >> > Tivoize the
> >> > result?
> 
> >> No.  This is not permission to relicense.  This is permission to
> >> combine.  Each author still gets to enforce the terms of her own code.
> 
> > This makes no sense. We are not talking mere aggregation here, we are
> > talking developmental convergence. If I wrote some code that was in the
> > Linux kernel, how can I enforce the terms of my code (guaranteed write to
> > Tivoize) in the derivative work that it becomes mixed with?
> 
> In just the same way you'd enforce it today: with help from a lawyer
> who understands these issues that you clearly don't understand.
> 
> >> So a tivoizer would have to take out the code licensed under the
> >> GPLv3, and use only the code that permits tivoization.  Same as today,
> >> but without the possibility of cooperation for licensees who don't
> >> tivoize.
> 
> > I am baffled how this could possibly work. You understand that the GPLv2
> > specifically guarantees that any derivative work will be Tivoizable and the
> > people who chose the GPLv2 specifically want it that way?
> 
> Yes.  And the GPLv2 code would remain that way.
> 
> If GPLv3 had this provision I suggested, and you wanted to cooperate
> with some other project that offered GPLv3 drivers, then you could use
> them by adding the mutual-cooperation provision I suggested.
> 
> Of course you're free to not want to cooperate with anyone else who
> doesn't share your opinion.  That's your call.
> 
> > If I chose the GPLv2 over the GPLv3 as a conscious choice, that means I want
> > people to be able to Tivoize any derivative work made from my work that is
> > distributed.
> 
> This provision was not intended to prevent anyone from tivoizing your
> work or derived works thereof.  It was only intended to enable you to
> use code from GPLv3 projects as long as these GPLv3 projects could
> also use your code.  Mutual cooperation, as opposed to no cooperation
> whatsoever.
> 
> I *think* lawyers would probably recommend you to keep code under
> different licenses in separate files, like you already do with code
> licensed under GPLv2-compatible licenses.
> 
> I *think* that, with this pair of mutual cooperation provisions, you
> could even use code licensed under the Apache 2.0 license.  And
> OpenSolaris drivers, if it's licensed under GPLv3.
> 
> And you wouldn't be departing from your intent to enable people to
> tivoize your code, which you currently choose not to enforce even
> though GPLv2 might very well enable you to; you could keep on
> cooperating with people who understand GPLv2 doesn't permit
> tivoization, and you'd be able to establish mutual cooperation with
> people who choose a license that makes this point clear.
> 
> It's not like anyone can safely tivoize devices with GPLv2 already, so
> refusing to cooperate with GPLv3 on these grounds buys you nothing.
> It is only a public statement of refusal to cooperate, with you are
> entitled to make, even if it comes off as silly because you chose a
> license that already contains the provisions for "complete
> corresponding source code" and "no further restrictions on the
> exercise of the rights granted by the license" that tivoizers fail to
> comply with.

So you really didn't pay any attention to anything people told you?

Ok, here are the relevant parts from GPLv2,

  The precise terms and conditions for copying, distribution and
  modification follow.

GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
^^^

  0. ... Activities other than copying, distribution and modification
  are not covered by this License; they are outside its scope. ...
  

  6. ... You may not impose any further restrictions on the recipients'
  exercise of the rights granted herein. ...
  

  11. ... THERE IS NO WARRANTY ... INCLUDING, BUT NOT LIMITED TO, THE
  IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
  PURPOSE. ...
  

The license does not grant the right that you will be able to run the
software on any particular platform or whether it will even work at all.

You are only granted the rights to _COPY_, _DISTRIBUTE_, and _MODIFY_.
Tivo in no way limits your ability to exercise any of these rights.

> FWIW, all of my (very few) contributions to Linux were made with the
> intent of not permitting tivoization or any form of restricting users
> freedoms.  I guess this means, from now on, you'd stop 

Re: [PATCH][AGPGART] intel_agp: don't load if no IGD and AGP port

[Wang Zhenyu]

On 2007.06.21 18:10:50 +, Carlo Wood wrote:
> 
> I am glad to see that you found a real reason for why it might have
> gone wrong. Just not initializing because it's not needed, but not
> understanding WHY it went wrong would have been rather unsatisfactory.
> 

yes, I understand, but it looks we did the wrong thing in the first step,
so... Thanks for testing this!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote:

> On Thu, Jun 21, 2007 at 05:15:03PM -0300, Alexandre Oliva wrote:
>> Anyone who's not happy about it can still take that portion out,
>> unless you accept changes that make this nearly impossible, which I
>> suppose you wouldn't given how strongly you feel about this.

> Oh, right.  "Anyone who doesn't like proprietary code in the tree
> can just remove it, what's the big deal?" analog.  Sorry, doesn't work.

Well, you do have proprietary code in Linux, and it's definitely not
easy to take it all out, so, point.

However, the difference that you appear to be missing is that when you
get code under GPLv3, or under this hypothetical combination of GPLv2
and GPLv3 code, everyone who received the combination could still do
everything the GPL says they could do: run the code for any purpose,
study it, adapt it, modify it and distribute it, with or without
modifications, under the same conditions, to the recipient, without
imposing any further restrictions.

The only thing that changes is that, for GPLv2, there's a possibility
that some licensees might be able to get away not permitting other
licensees to do the things the license you chose permits them to do,
using tricks that have been invented or that became matter of new laws
since GPLv2 was published.

But this doesn't mean GPLv2 unambiguously permits this behavior; that
you want it to doesn't make it so for all contributors.  Just like you
have the right to veto any additional permissions on Linux, so can
other contributors.  And unambiguous permission to tivoize is an
additional permission, just like permission to combine code with GPLv3
is an additional permission.

Heck, even the requirement to provide source code under GPLv1 and
GPLv2 is a clarification along the same lines of the new provisions of
GPLv3.  Denying access to the source code is a restriction on the
exercise of the rights granted by the license.  So it's implied.  But
since some people might not see it that way, it's spelled out in full.
Same deal with patents in GPLv2, and all the other new provisions with
GPLv3.  What makes them incompatible is not that they impose new
restrictions (they really don't), it's that they remove any doubts
about that.


>> I can see that one-way cooperation could be perceived as unfair, even
>> if permissions granted by GPLv3 are all granted by GPLv2 as well.

> ... but not the other way round.  So in effect we get a change of kernel
> license, GPLv3 people *do* *not* get any license changes on their projects.
> And you are saying that it's not one-way?

GPLv3 people *do* get license changes too.  This can be accomplished
with additional permissions on both licenses with the current GPLv3
draft.  I'm proposing that this backward compatibility could be a
built-in feature of GPLv3.

As to whether this has any effects on GPLv3 projects, it does.  It
weakens the legal defenses for the entire project, in as much as the
wholes in GPLv2 might still be exploited.

>> > ... except for that pesky "no added restrictions" part, but hey, who
>> > cares?

>> But see, nobody would be adding restrictions to *your* code.

> What you are saying is "but your code will be still
> available under GPLv2".

No, I'm saying far more than this obvious conclusion, on which you
apparently stopped thinking.

I'm saying the project that uses it won't get as strong legal defenses
as it would get if it were under GPLv3.  So, yes, both sides sacrifice
some of their stances in order to enable mutual cooperation.

Sure, if you don't want to do that, that's your call.  But don't try
to frame it as if there was something wrong or unfair about it.

> So it will be if e.g. SCO pulls it into proprietary codebase.

Except that then I won't be able to enjoy any of the rights that you
meant me to enjoy as to the code that SCO distributes.

Whereas with combination of GPLv2 with GPLv3, every licensee still
gets all of the same freedoms respected.  The difference is only as to
how much they can deny other licensees the freedoms you meant them to
get.

And if someone cares about using your code to deny other licensees
freedoms, they still can.  Depending on how much you intermingled your
code with code that doesn't want to permit this, it will be more or
less difficult to do, but it can be done.

> The first change in v3 project affecting both imported v2 code and
> native v3 one will create a big problem.

Why?  The licenses permit combination/linking, each portion remains
under the same license as their authors meant.

>> > ... because it's For The Benefit Of User Freedoms!!!

>> It is either way.  Do you deny that tivoization also benefits one
>> user/licensee?  And in detriment of others, while at that?

> You know, we have another wanker here starting another thread from
> hell - one about allowing stable driver ABI, to make the life of
> proprietary modules more convenient.

And it's indeed the same issue: placing the interests of a few

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Chris Mason]

On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
> On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote:
> > 
> > > > A veto is not a technical argument. All technical arguments (except for
> > > > "path name is ugly, yuk yuk!") have been addressed, have they not?
> > > AppArmor doesn't actually provide confinement, because it only operates 
> > > on 
> > > filesystem objects.
> > > 
> > > What you define in AppArmor policy does _not_ reflect the actual 
> > > confinement properties of the policy.  Applications can simply use other 
> > > mechanisms to access objects, and the policy is effectively meaningless.
> > 
> > Only if they have access to another process which provides them with
> > that data.
> 
> Or can access the data under a different path to which their profile
> does give them access, whether in its final destination or in some
> temporary file processed along the way.
> 
> > And now, yes, I know AA doesn't mediate IPC or networking (yet), but
> > that's a missing feature, not broken by design.
> 
> The incomplete mediation flows from the design, since the pathname-based
> mediation doesn't generalize to cover all objects unlike label- or
> attribute-based mediation.  And the "use the natural abstraction for
> each object type" approach likewise doesn't yield any general model or
> anything that you can analyze systematically for data flow.

This feels quite a lot like a repeat of the discussion at the kernel
summit.  There are valid uses for path based security, and if they don't
fit your needs, please don't use them.  But, path based semantics alone
are not a valid reason to shut out AA.

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[David Schwartz]

Alexandre Oliva wrote:

> Now, if you guys can't recognize a goodwill gesture when you see one,
> and prefer to live in the paranoid beliefs that "those evil FSFers are
> trying to force me into a situation in which they'll then be able to
> steal my code", that's really up to you.  Don't try to shift the blame
> of your decisions onto the FSF.

> Hey, but that was precisely what I was suggesting!  Except that it
> wasn't with GPLv2 alone, because this doesn't work.  Each copyleft
> license insists that it be *the* license.  So, in order to be able to
> combine two copyleft licenses, you need mutual compatibility
> provisions in both.  Which is what I was proposing.

It's this simple, those who chose the GPLv2 for Linux and their
contributions to it don't want people to create derivative works of their
works that can't be Tivoized. They see this as a feature, and it's the
reason they're not willing to adopt GPLv3. (They want people who receive
derivative works of their programs to get all the GPLv2 rights, not just
some of them.)

I don't see any compromise that means that people don't get all the rights
to Linux that the GPLv2 grants as working.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[david]

On Thu, 21 Jun 2007, Joshua Brindle wrote:


Lars Marowsky-Bree wrote:

 On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
 


>  Um, no.  It might not be able to directly open files via that path, but
>  showing that it can never read or write your mail is a rather different
>  matter.
> 


 Yes. Your use case is different than mine.



So.. your use case is what? If an AA user asked you to protect his mail from 
his browser I'm sure you'd truthfully answer "no, we can't do that but we can 
protect the path to your mail from your browser".. I think not. One need only 
look at the wonderful marketing literature for AA to see what you are telling 
people it can do, and your above statement isn't consistent with that, sorry.


remember, the policies define a white-list

so if a hacker wants to have mozilla access the mail files he needs to get 
some other process on the sysstem to create a link or move a file to a 
path that mozilla does have access to. until that is done there is no way 
for mozilla to access the mail through the filesystem.


other programs could be run that would give mozilla access to the mail 
contents, but it would be through some other path that the policy 
permitted mozilla accessing in the first place.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[david]

On Thu, 21 Jun 2007, Alexandre Oliva wrote:


On Jun 21, 2007, [EMAIL PROTECTED] wrote:


this is your right with your code. please stop browbeating people who
disagree with you.


For the record, GPLv2 is already meant to accomplish this.  I don't
understand why people who disagree with this stance chose GPLv2.
Isn't "no further restrictions" clear enough?


everyone else is reading this as 'no further license restrictions' not 'no 
hardware restrictions' becouse GPLv2 explicitly says that it has nothing 
to do with running the software, only with distributing it.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

On 2007-06-21T20:16:25, Joshua Brindle <[EMAIL PROTECTED]> wrote:

> not. One need only look at the wonderful marketing literature for AA to 
> see what you are telling people it can do, and your above statement 
> isn't consistent with that, sorry.

I'm sorry. I don't work in marketing.


-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.22-rc5: pdflush oops under heavy disk load

[Jay L. T. Cornwall]

Hi,

Kernel version: 2.6.22-rc5 (confirmed also on 2.6.20)
Kernel config : Ubuntu 7.04 default (SMP)

Relevant hardware:
  Asus P5K (Intel P35 chipset)
  Core 2 Duo E6600 2.4GHz
  Western Digital 10KRPM 150GB HDD on JMicron 20360/20363 AHCI

Netconsoled dump:

[  724.350222] general protection fault:  [1] SMP
[  724.350413] CPU 1
[  724.350520] Modules linked in: usb_storage libusual netconsole
binfmt_misc rfcomm l2cap bluetooth ppdev capability commoncap
acpi_cpufreq cpufreq_stats cpufreq_userspace cpufreq_ondemand
cpufreq_conservative cpufreq_powersave freq_table video container
battery dock asus_acpi ac sbs button af_packet nls_utf8 ntfs w83627ehf
i2c_isa parport_pc lp parport fuse mt2060 snd_hda_intel snd_pcm_oss
snd_mixer_oss snd_pcm cx22702 snd_seq_dummy snd_seq_oss dvb_usb_dib0700
dib7000m dib7000p dvb_usb cx88_dvb cx88_vp3054_i2c snd_seq_midi
snd_rawmidi video_buf_dvb dvb_core ipv6 snd_seq_midi_event snd_seq
snd_timer dvb_pll cx8800 cx8802 cx88xx sr_mod ir_common snd_seq_device
cdrom i2c_algo_bit dib3000mc dibx000_common tveeprom atl1 usbhid psmouse
videodev compat_ioctl32 hid mii i2c_core v4l2_common v4l1_compat
btcx_risc video_buf serio_raw snd soundcore pcspkr shpchp pci_hotplug
snd_page_alloc intel_agp tsdev evdev ext3 jbd mbcache sg sd_mod
pata_jmicron ata_generic ata_piix ahci libata scsi_mod ehci_hcd generic
uhci_hcd usbcore thermal processor fan
[  724.355028] Pid: 199, comm: pdflush Not tainted 2.6.22-rc5-edge #1
[  724.355125] RIP: 0010:[]  []
:ext3:walk_page_buffers+0x34/0x90
[  724.355305] RSP: 0018:8101322e7bb0  EFLAGS: 00010202
[  724.355394] RAX:  RBX: 9d8145bd RCX:
1000
[  724.355491] RDX: 9d8145bd RSI: 908553557cc5eb6f RDI:
81012e1052a0
[  724.355587] RBP: 3b028b7a R08:  R09:
880f1ba0
[  724.355684] R10:  R11: 0001 R12:
9d8145bd
[  724.355780] R13: 908553557cc5eb6f R14: 8100369a5200 R15:

[  724.357278] FS:  () GS:81013b07cac0()
knlGS:
[  724.357410] CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
[  724.357501] CR2: 2b776e178000 CR3: 00013a245000 CR4:
06e0
[  724.357598] Process pdflush (pid: 199, threadinfo 8101322e6000,
task 81013b15aaa0)
[  724.357730] Stack:  880f1ba0 1000
81012e1052a0 81013de27c38
[  724.358031]  81012e1052a0 2e1052a0 8100369a5200
8101322e7e50
[  724.358292]  000e 880f4fca 81012e545b08
0003
[  724.358489] Call Trace:
[  724.358638]  [] :ext3:bget_one+0x0/0x10
[  724.358742]  [] :ext3:ext3_ordered_writepage+0xea/0x190
[  724.358846]  [] __writepage+0xa/0x30
[  724.358937]  [] write_cache_pages+0x224/0x350
[  724.359030]  [] __writepage+0x0/0x30
[  724.359147]  [] do_writepages+0x2b/0x40
[  724.359239]  [] __writeback_single_inode+0xa6/0x3e0
[  724.359348]  [] sync_sb_inodes+0x1f6/0x2f0
[  724.359445]  [] writeback_inodes+0xbf/0x100
[  724.359542]  [] background_writeout+0xa9/0xe0
[  724.359648]  [] pdflush+0x0/0x220
[  724.359739]  [] pdflush+0x140/0x220
[  724.359829]  [] background_writeout+0x0/0xe0
[  724.359927]  [] kthread+0x4b/0x80
[  724.360018]  [] child_rip+0xa/0x12
[  724.360120]  [] kthread+0x0/0x80
[  724.360208]  [] child_rip+0x0/0x12
[  724.360298]
[  724.360369]
[  724.360370] Code: 4c 8b 6e 08 41 8d 1c 14 76 39 89 d8 44 29 e0 3b 44
24 08 73
[  724.361260] RIP  [] :ext3:walk_page_buffers+0x34/0x90
[  724.361395]  RSP 

The system runs stably under light load. Heavy disk writes, here induced
by 200Mbit scp's onto the drive, cause the oops within a minute or two.
It's entirely reproducible and appears to give the same trace each time.

I'll have a go at digging up the root of this problem, but anyone with
more experience is welcome to pitch in!

-- 
Jay L. T. Cornwall, http://www.esuna.co.uk/~jay/
PhD Student
Imperial College London
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Joshua Brindle]

Lars Marowsky-Bree wrote:

On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:


  

Um, no.  It might not be able to directly open files via that path, but
showing that it can never read or write your mail is a rather different
matter.



Yes. Your use case is different than mine.
  


So.. your use case is what? If an AA user asked you to protect his mail 
from his browser I'm sure you'd truthfully answer "no, we can't do that 
but we can protect the path to your mail from your browser".. I think 
not. One need only look at the wonderful marketing literature for AA to 
see what you are telling people it can do, and your above statement 
isn't consistent with that, sorry.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: This is [Re:] How to improve the quality of the kernel[?].

[Adrian Bunk]

On Thu, Jun 21, 2007 at 04:59:39PM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 22 Jun 2007, Adrian Bunk wrote:
> > On Tue, Jun 19, 2007 at 10:04:58AM -0700, Linus Torvalds wrote:
> > >...
> > > This is why I've been advocating bugzilla "forget" stuff, for example. I 
> > > tend to see bugzilla as a place where noise accumulates, rather than a 
> > > place where noise is made into a signal. 
> > > 
> > > Which gets my to the real issue I have: the notion of having a process 
> > > for 
> > > _tracking_ all the information is actually totally counter-productive, if 
> > > a big part of the process isn't also about throwing noise away.
> > > 
> > > We don't want to "save" all the crud. I don't want "smart tracking" to 
> > > keep track of everything. I want "smart forgetting", so that we are only 
> > > left with the major signal - the stuff that matters. 
> > 
> > Even generating the perfect signal is a complete waste of time if 
> > there's no recipient for the signal...
> 
> My argument is that *if* we had "more signal, less noise", we'd probably 
> get more people looking at it.
> 
> In fact, I guarantee that's the case. You may  not be 100% happy with the 
> regression list, but every single maintainer/developer I've talked to has 
> said they appreciated it and it made it easier (and thus more likely) for 
> them to actually look at what the outstanding issues were.


The problems are the parts of the kernel without maintainer or with a 
maintainer who is for whatever reason not able to look after bug 
reports.

And you often need someone with a good knowledge of a specific area of 
the kernel for getting a bug fixed.


Let me make an example:

During 2.6.16-rc, I reported a bug (not a regression) in CIFS where I 
had reproducible during big writes to a Samba server after some 100 MBs 
(not a fixed amount of data, but 100% reproducible when transferring 1 GB)
a complete freeze of my computer (no SysRq possible). And there is
nothing more I (or any other submitter) could have given as information -
in fact it even took me several days to isolate CIFS as the source of 
these freezes.

Steve French and Dave Kleikamp told me to try some mount option.

With this option, I got an Oops instead of a freeze.

After they fixed the Oops, it turned out the patch also fixed the 
freeze. The patch went into 2.6.16, and it was therefore fixed
in 2.6.16.

That's one important value of maintainers.

In many other parts of the kernel, my bug report wouldn't have had any 
effect.


We need more maintaners who look after bugs - but where to find them, 
they don't seem to grow on trees?


>   Linus

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 21, 2007, "Jesper Juhl" <[EMAIL PROTECTED]> wrote:

> My point was that your signature does indicate your affiliation with a
> lot of different organizations/companies, so unless you explicitly
> state that you are not speaking on behalf of them it's easy to assume
> you do.

And then, I did that a number of times in the other recent long
thread, whenever I made statements that could be construed as FSF's
opinion.  Now, this time I missed it, added the clarification just in
case, and you pick on me.  Puhlease!

> Quoting from that web page: "FSF Latin America is a sister
> organization of Free Software Foundation (FSF)"

> So when your signature states that you are a "FSF Latin America Board
> Member" and FSFLA is a "sister organization of Free Software
> Foundation (FSF)" that, at least to me, implies some association with
> the FSF.

How does that make me an FSF Board Member, as you claimed at first?

Yes, I'm a co-founder of an independent organization that, for sharing
the same goals as other FSFs, was welcomed into the global network of
FSFes.

That we have the same goals does not imply I'm in any way associated
with the FSF.  Your faulty assumption and your attempts to paper over
your mistake won't make it true.

> No, it does not, but it's easy to mistake a post by someone posting
> from a company email and including that company in their signature for
> speaking for that company.

Indeed, compiler engineers are often the bearers of company's voices.

Not!

> I'm simply replying to you that indeed it is not clear for whom you
> speak with all that info in your signature and the email address you
> post from.

Understood.  Thanks for doing that so nicely.

I'm glad it's clear now.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86_64: Fix misplaced `continue' in mce.c

[Joshua Wise]

From: Joshua Wise <[EMAIL PROTECTED]>

Background:
 When a userspace application wants to know about machine check events, it
 opens /dev/mcelog and does a read(). Usually, we found that this interface
 works well, but in some cases, when the system was taking large numbers of
 machine check exceptions, the read() would hang. The system would output a
 soft-lockup warning, and the daemon reading from /dev/mcelog would suck up
 as much of a single CPU as it could spinning in system space.

Description:
 This patch fixes this bug. In particular, there was a "continue" inside a
 timeout loop that presumably was intended to break out of the outer loop,
 but instead caused the inner loop to continue. This patch also makes the
 condition for the break-out a little more evident by changing a
 !time_before to a time_after_eq.

Result:
 The read() no longer hangs in this test case.

Testing:
 On my system, I could replicate the bug with the following command:
   # for i in `seq 15000`; do ./inject_sbe.sh; done
 where inject_sbe.sh contains commands to inject a single-bit error into the
 next memory write transaction.

Patch:
 This patch is against git f1518a088bde6aea49e7c472ed6ab96178fcba3e.

Signed-off-by: Joshua Wise <[EMAIL PROTECTED]>
Signed-off-by: Tim Hockin <[EMAIL PROTECTED]>

--

diff --git a/arch/x86_64/kernel/mce.c b/arch/x86_64/kernel/mce.c
index a14375d..aa83023 100644
--- a/arch/x86_64/kernel/mce.c
+++ b/arch/x86_64/kernel/mce.c
@@ -497,15 +497,17 @@ static ssize_t mce_read(struct file *fil
for (i = 0; i < next; i++) {
unsigned long start = jiffies;
while (!mcelog.entry[i].finished) {
-   if (!time_before(jiffies, start + 2)) {
+   if (time_after_eq(jiffies, start + 2)) {
memset(mcelog.entry + i,0, sizeof(struct mce));
-   continue;
+   goto timeout;
}
cpu_relax();
}
smp_rmb();
err |= copy_to_user(buf, mcelog.entry + i, sizeof(struct mce));
 		buf += sizeof(struct mce); 
+	 timeout:

+   ;
}

memset(mcelog.entry, 0, next * sizeof(struct mce));
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine

[Robert Hancock]

Peter Rabbitson wrote:

H. Peter Anvin wrote:

Peter Rabbitson wrote:

I have captured dmesg output without mem[5], with mem=3900M[6] and
mem=2048M[7].



What does /proc/mtrr look like in the two cases?



Identical for mem=3900 and without it.

reg00: base=0x (   0MB), size=2048MB: write-back, count=1
reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc000 (3072MB), size= 512MB: write-back, count=1
reg03: base=0xe000 (3584MB), size= 256MB: write-back, count=1
reg04: base=0xf000 (3840MB), size= 128MB: write-back, count=1
reg05: base=0xf800 (3968MB), size=  32MB: write-back, count=1


Looks like another case of bad MTRRs on an Intel motherboard? The BIOS 
is marking only memory up to 4000MB as cacheable, but the actual memory 
extends up to about 4031MB. Therefore anything that accesses the top 
31MB of memory will run very slow.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 21, 2007, [EMAIL PROTECTED] wrote:

> this is your right with your code. please stop browbeating people who
> disagree with you.

For the record, GPLv2 is already meant to accomplish this.  I don't
understand why people who disagree with this stance chose GPLv2.
Isn't "no further restrictions" clear enough?

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: This is [Re:] How to improve the quality of the kernel[?].

[Linus Torvalds]

On Fri, 22 Jun 2007, Adrian Bunk wrote:
> On Tue, Jun 19, 2007 at 10:04:58AM -0700, Linus Torvalds wrote:
> >...
> > This is why I've been advocating bugzilla "forget" stuff, for example. I 
> > tend to see bugzilla as a place where noise accumulates, rather than a 
> > place where noise is made into a signal. 
> > 
> > Which gets my to the real issue I have: the notion of having a process for 
> > _tracking_ all the information is actually totally counter-productive, if 
> > a big part of the process isn't also about throwing noise away.
> > 
> > We don't want to "save" all the crud. I don't want "smart tracking" to 
> > keep track of everything. I want "smart forgetting", so that we are only 
> > left with the major signal - the stuff that matters. 
> 
> Even generating the perfect signal is a complete waste of time if 
> there's no recipient for the signal...

My argument is that *if* we had "more signal, less noise", we'd probably 
get more people looking at it.

In fact, I guarantee that's the case. You may  not be 100% happy with the 
regression list, but every single maintainer/developer I've talked to has 
said they appreciated it and it made it easier (and thus more likely) for 
them to actually look at what the outstanding issues were.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Kernel include files

[Arnd Bergmann]

On Friday 22 June 2007, [EMAIL PROTECTED] wrote:
> this has been discussed many times and the answer is that the kernel is 
> not gong to change it's side of things to ANSI C.

I don't think that's entirely true with regard to the include files.
We have always tried not to step on anyone's toes there, e.g. regarding
the use of __u32 vs. uint32_t style types. It's certainly desirable
to make the kernel headers that are _meant_ for inclusion compatible
with standard compilers.

Mike Frysinger has posted a few patches that make the installed headers
friendlier to strict C99 users. While there was some negative feedback
about these patches, it was not about the idea of making the installed
headers C99 clean, but rather about the question whether those non-clean
parts should be exported in the first place.

Now whether a specific header file should be installed and potentially
included in user space is certainly debatable in many cases, but at
least it's now clearly defined through the include/*/Kbuild files.
If someone has a good reason to change which files are exported, he
should simply submit a patch against the list of exported files.

> that doesn't mean that one of the many projects out there to create 
> seperate interface headers won't do this.

Those projects are all practically dead, since we have the
'make headers_install' target in the Linux source.

Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 21, 2007, Andrew McKay <[EMAIL PROTECTED]> wrote:

> Alexandre Oliva wrote:
>> On Jun 21, 2007, Andrew McKay <[EMAIL PROTECTED]> wrote:
>> 
>>> A balance of freedom to the licensee and the licenser.  It's my
>>> opinion that GPLv3 potentially shifts the balance too far to the
>>> licensee.
>> 
>> It's more of a balance of freedom between licensee and licensee,
>> actually.  It's a lot about making sure no one can acquire a
>> privileged position, such that every licensee plays under the same
>> rules.  (The copyright holder is not *acquiring* a privileged
>> position, copyright law had already granted him/her that position.)

> I do see what you're saying here.  But it does take the away the
> ability of a licensee to protect themselves from another malicious
> licensee.

Sorry, I don't follow what the "it" refers to in your sentence.

> If the ultimate goal of the Free Software community is to get source
> code out to the public, I think that was captured in GPLv2.

That's a correct logical inference, but since the premise is false,
the conclusion is garbage.

GPLv2 goes far beyond getting source code out to the public.  It
contains the "no further restrictions" language, which is very
powerful.  It is pretty obvious that when Linus adopted GPLv2 he
didn't realize it reached that point.  That when Tivo invented
Tivoization, he decided he wanted to permit this, and thus grants an
implicit additional permission for anyone to do it with his code,
doesn't mean other participants in the Linux community feel the same
way, or read the GPLv2 the same way, and could be somehow stopped from
enforcing the license the way they meant it.

Ultimately, the current situation is that we have two
mutually-incompatible license intents being used in Linux, and no
matter how much those who want to grant the permission say so, this
doesn't trample other contributor's rights to enforce the license they
chose for their code.  Especially those who started contributing long
before the decision that "what TiVo does is good" was announced.

Now, since these two license intents are expressed by the same
license, and what the license demands is that derived works must be
under the same license, they are compatible, but since the intents are
distinct, what prevails is, as in any case of combination of different
licensing provisions, is the most restrictive provision.

So Linux does not permit tivoization today.  Linus does, Linux
doesn't.

All this fuss about the anti-tivoization provisions in GPLv3 is just a
consequence of reading the GPLv2 without fully understanding its
intended consequences, not having foresight to clarify the intent to
constrain the "no further restrictions" provisions to match the
alternate interpretation, and opposing the removal of the ambiguity
because it doesn't match the choice that *some* of the developers
would like it to go.

Who's the ambiguity good for?

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Broadcom (bnx2) on PE1950/2950 failure

[Robert Hancock]

Fortier,Vincent [Montreal] wrote:

Here is part of the dmesg:
[EMAIL PROTECTED] /root]# dmesg | grep -i eth
[  119.196375] Broadcom NetXtreme II Gigabit Ethernet Driver bnx2
v1.5.8.1 (May 7, 2007)
[  119.215023] eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X
64-bit 133MHz found at mem f800, IRQ 17, node addr 0019b9c8eedc
[  119.246853] eth1: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X
64-bit 133MHz found at mem f400, IRQ 16, node addr 0019b9c8eede
[  119.458598] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network
Connection
[  119.654095] e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network
Connection
[  266.513144] bnx2: eth3: using MSI
[  269.638237] bnx2: eth3 NIC Link is Up, 1000 Mbps full duplex, receive
& transmit flow control ON
[  290.242533] eth3: no IPv6 routers present

As you can notice it tried to use eth0 & eth1 for both broadcom adapters
but it did not worked properly since e1000 used them instead and finally
bnx2 got eth3 working using MSI ?


Huh? eth0 and eth1 are the e1000 adapters, eth3 (and presumably eth2) 
are the bnx2 adapters..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] mark calibrate_xor_blocks() __init

[Adrian Bunk]

On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.22-rc4-mm1:
>...
>  git-md-accel.patch
>...
>  git trees
>...

calibrate_xor_blocks() can be marked __init.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
--- linux-2.6.22-rc4-mm2/crypto/xor.c.old   2007-06-21 23:47:56.0 
+0200
+++ linux-2.6.22-rc4-mm2/crypto/xor.c   2007-06-21 23:48:39.0 +0200
@@ -94,7 +94,7 @@
   speed / 1000, speed % 1000);
 }
 
-static int
+static int __init
 calibrate_xor_blocks(void)
 {
void *b1, *b2;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Kernel include files

[Arjan van de Ven]

> Cdrtools ftp://ftp.berlios.de/pub/cdrecord/alpha/ offer support for an OS 
> dependent SCSI transport. Cdrtools cannot be compiled wihout support for SCSI 
> transport, so it is impossible to use Sun Studio to compile cdrtools.
> 
> Why does this happen?
> 
> Well, the reason is that in order to support Linux specific features, you 
> need 
> to include Linux specific include files (the Linux kernel include files).


I assume you typoed and meant "cleaned up kernel include files as
installed by make headers_install" instead.

>  As 
> these include files are currently not written in vanilla (ANSI) C but in a 
> GCC-C-variant, other compilers do not like these include files.

can you give a specific example of a header installed by make
headers_install that breaks this way and is hurting you? Because it may
well be possible to fix the problems, now that we have this special
cleanup phase since several releases


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] cafe_nand.c: the OLPC laptop is not available for $100

[Adrian Bunk]

The price might drop to $100 in a few years.

But currently, a more reasonable name might be "$175 laptop".

Let's simply call it "OLPC laptop" without any price tag.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
--- linux-2.6.22-rc4-mm2/drivers/mtd/nand/Kconfig.old   2007-06-21 
23:32:02.0 +0200
+++ linux-2.6.22-rc4-mm2/drivers/mtd/nand/Kconfig   2007-06-21 
23:32:17.0 +0200
@@ -234,13 +234,13 @@
 config MTD_NAND_CAFE
tristate "NAND support for OLPC CAFÉ chip"
depends on PCI
select REED_SOLOMON
select REED_SOLOMON_DEC16
help
- Use NAND flash attached to the CAFÉ chip designed for the $100
+ Use NAND flash attached to the CAFÉ chip designed for the OLPC
  laptop.
 
 config MTD_NAND_CS553X
tristate "NAND support for CS5535/CS5536 (AMD Geode companion chip)"
depends on X86_32 && (X86_PC || X86_GENERICARCH)
help

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC: 2.6 patch] schedule BLK_DEV_IDE_SATA for removal

[Adrian Bunk]

Users should use the libata based drivers for SATA drives.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
--- linux-2.6.22-rc4-mm2/Documentation/feature-removal-schedule.txt.old 
2007-06-21 23:41:03.0 +0200
+++ linux-2.6.22-rc4-mm2/Documentation/feature-removal-schedule.txt 
2007-06-21 23:42:03.0 +0200
@@ -347,3 +347,10 @@
 Who:   Jean Delvare <[EMAIL PROTECTED]>
 
 ---
+
+What:  CONFIG_BLK_DEV_IDE_SATA
+When:  December 2007
+Why:   users should use the libata based drivers for SATA
+Who:   Adrian Bunk <[EMAIL PROTECTED]>
+
+---

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC: 2.6.22 patch] don't offer DISPLAY_SUPPORT for now

[Adrian Bunk]

DISPLAY_SUPPORT offers support code without any users currently in the 
tree. For a user it's quite confusing that the help text talks about
"proper drivers" when none are available.

This patch therefore lets DISPLAY_SUPPORT depend on BROKEN until there 
will be user.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
--- linux-2.6.22-rc4-mm2/drivers/video/display/Kconfig.old  2007-06-21 
18:41:26.0 +0200
+++ linux-2.6.22-rc4-mm2/drivers/video/display/Kconfig  2007-06-21 
18:41:41.0 +0200
@@ -1,24 +1,25 @@
 #
 # Display drivers configuration
 #
 
 menu "Display device support"
 
 config DISPLAY_SUPPORT
tristate "Display panel/monitor support"
+   depends on BROKEN  #  lacks users
---help---
  This framework adds support for low-level control of a display.
  This includes support for power.
 
  Enable this to be able to choose the drivers for controlling the
  physical display panel/monitor on some platforms. This not only
  covers LCD displays for PDAs but also other types of displays
  such as CRT, TVout etc.
 
  To have support for your specific display panel you will have to
  select the proper drivers which depend on this option.
 
 comment "Display hardware drivers"
depends on DISPLAY_SUPPORT
 
 endmenu



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: This is [Re:] How to improve the quality of the kernel[?].

[Adrian Bunk]

On Tue, Jun 19, 2007 at 10:04:58AM -0700, Linus Torvalds wrote:
>...
> This is why I've been advocating bugzilla "forget" stuff, for example. I 
> tend to see bugzilla as a place where noise accumulates, rather than a 
> place where noise is made into a signal. 
> 
> Which gets my to the real issue I have: the notion of having a process for 
> _tracking_ all the information is actually totally counter-productive, if 
> a big part of the process isn't also about throwing noise away.
> 
> We don't want to "save" all the crud. I don't want "smart tracking" to 
> keep track of everything. I want "smart forgetting", so that we are only 
> left with the major signal - the stuff that matters. 

Even generating the perfect signal is a complete waste of time if 
there's no recipient for the signal...

>   Linus

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC: 2.6 patch] allow disabling DNOTIFY without EMBEDDED

[Adrian Bunk]

This patch allows disabling DNOTIFY with CIONFIG_EMBEDDED=n.

I'm currently running a kernel with dnotify disabled and I haven't run 
into any problem. Is there any popular application left that breaks 
without dnotify support in the kernel?

Note that this patch does not remove dnotify support, it still defaults
to "y", and the help text recommends enabling it.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
--- linux-2.6.22-rc4-mm2/fs/Kconfig.old 2007-06-21 18:25:20.0 +0200
+++ linux-2.6.22-rc4-mm2/fs/Kconfig 2007-06-21 18:25:54.0 +0200
@@ -585,17 +585,17 @@
depends on XFS_QUOTA || QUOTA
default y
 
 config DNOTIFY
-   bool "Dnotify support" if EMBEDDED
+   bool "Dnotify support"
default y
help
  Dnotify is a directory-based per-fd file change notification system
  that uses signals to communicate events to user-space.  There exist
  superior alternatives, but some applications may still rely on
  dnotify.
 
- Because of this, if unsure, say Y.
+ If unsure, say Y.
 
 config AUTOFS_FS
tristate "Kernel automounter support"
help

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Please release a stable kernel Linux 3.0

[Arjan van de Ven]

On Thu, 2007-06-21 at 19:08 -0400, Chuck Ebbert wrote:
> On 06/21/2007 07:01 PM, Lennart Sorensen wrote:
> > On Thu, Jun 21, 2007 at 06:34:20PM -0400, Chuck Ebbert wrote:
> >> Even the good ones that get lots of fixes aren't all that good. The
> >> biggest problem ATM is that suspend is badly broken and keeps getting
> >> worse...
> > 
> > I wasn't under the impression suspend had really ever worked.  Such a
> > messy problem to solve.
> > 
> 
> It never worked reliably for everyone, but with each new release it
> seems to get worse.

the thing is just fundamentally not designed right. Declaring it stable
ain't gonna fix that. Having someone do a right design (which will
obviously will go through some breakage period, even if it's an
evolution of the current design) is a required step of getting s/r more
reliable... but the current one doesn't get stable just by declaring it
so.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: This is [Re:] How to improve the quality of the kernel[?].

[Adrian Bunk]

On Tue, Jun 19, 2007 at 08:01:19AM -0700, Linus Torvalds wrote:
> On Tue, 19 Jun 2007, Adrian Bunk wrote:
>...
> > The -mm kernel already implements what your proposed PTS would do.
> > 
> > Plus it gives testers more or less all patches currently pending 
> > inclusion into Linus' tree in one kernel they can test.
> > 
> > The problem are more social problems like patches Andrew has never heard 
> > of before getting into Linus' tree during the merge window.
> 
> Not really. The "problem" boils down to this:
> 
>   [EMAIL PROTECTED] linux]$ git-rev-list --all --since=100.days.ago | wc 
> -l
>   7147
>   [EMAIL PROTECTED] linux]$ git-rev-list --no-merges --all 
> --since=100.days.ago | wc -l
>   6768
> 
> ie over the last hundred days, we have averaged over 70 changes per day, 
> and even ignoring merges and only looking at "pure patches" we have more 
> than an average of 65 patches per day. Every day. Day in and day out.
> 
> That translates to five hundred commits a week, two _thousand_ commits per 
> month, and 25 thousand commits per year. As a fairly constant stream.
> 
> Will mistakes happen? Hell *yes*. 
> 
> And I'd argue that any flow that tries to "guarantee" that mistakes don't 
> happen is broken. It's a sure-fire way to just frustrate people, simply 
> because it assumes a level of perfection in maintainers and developers 
> that isn't possible.
> 
> The accepted industry standard for bug counts is basically one bug per a 
> thousand lines of code. And that's for released, *debugged* code. 
> 
> Yes, we should aim higher. Obviously. Let's say that we aim for 0.1 bugs 
> per KLOC, and that we actually aim for that not just in _released_ code, 
> but in patches.
> 
> What does that mean?
> 
> Do the math:
> 
>   git log -M -p --all --since=100.days.ago | grep '^+' | wc -l
> 
> That basically takes the last one hundred days of development, shows it 
> all as patches, and just counts the "new" lines. It takes about ten 
> seconds to run, and returns 517252 for me right now.
> 
> That's *over*half*a*million* lines added or changed!
> 
> And even with the expectation that we do ten times better than what is 
> often quoted as an industry average, and even with the expectation that 
> this is already fully debugged code, that's at least 50 bugs in the last 
> one hundred days.
> 
> Yeah, we can be even more stringent, and actually subtract the number of 
> lines _removed_ (274930), and assume that only *new* code contains bugs, 
> and that's still just under a quarter million purely *added* lines, and 
> maybe we'd expect just new 24 bugs in the last 100 days.
> 
> [ Argument: some of the old code also contained bugs, so the lines added 
>   to replace it balance out. Counter-argument: new code is less well 
>   tested by *definition* than old code, so.. Counter-counter-argument: the 
>   new code was often added to _fix_ a bug, so the code removed had an even 
>   _higher_ bug rate than normal code.. 
> 
>   End result? We don't know. This is all just food for thought. ]
> 
> So here's the deal: even by the most *stringent* reasonable rules, we add 
> a new bug every four days. That's just something that people need to 
> accept. The people who say "we must never introduce a regression" aren't 
> living on planet earth, they are living in some wonderful world of 
> Blarney, where mistakes don't happen, developers are perfect, hardware is 
> perfect, and maintainers always catch things.
>...

Exactly: We cannot get a regression free or even bug free kernel.
But we could handle the reported regressions (or even the reported bugs) 
better than we do.

Lesson #6:
Get the data.

Some real life numbers from 2.6.21 development:
- 80 days between 2.6.20 and 2.6.21
- 98 post-2.6.20 regression have been reported before 2.6.21 was released
- 15 open post-2.6.20 regression reports at the time of the 2.6.21 release
- 8 open post-2.6.20 regression reports at the time of the 2.6.21 release
that were reported at least 3 weeks before the 2.6.21 release

This:
- only includes regressions with reasonably usable reports [1] and
- confirmed to be regressions and
- reported by the relatively small number (compared to the complete
  number of Linux users) of -rc testers and
- reported before the release of 2.6.21.

We weren't even able to handle all reported recent regressions in 
2.6.21, and for other bugs our numbers won't be better.

When Dave Jones says that for a kernel for a new RHEL release that is 
based on a "stable" upstream kernel they spend 3 months only for shaking 
out bugs in the kernel that's IMHO a good description of our "stable" 
kernels.

I'm not claiming the kernel could become bug-free, but aiming at being 
able to handle all incoming bug reports is IMHO a worthwhile and not 
completely unrealistic goal with benefits for all Linux users (and the 
overall image of Linux).

Currently, we are light years away from this goal.

>   Linus

cu
Adrian

[1] submitter has 

Re: Please release a stable kernel Linux 3.0

[Måns Rullgård]

Chuck Ebbert <[EMAIL PROTECTED]> writes:

> On 06/21/2007 07:01 PM, Lennart Sorensen wrote:
>> On Thu, Jun 21, 2007 at 06:34:20PM -0400, Chuck Ebbert wrote:
>>> Even the good ones that get lots of fixes aren't all that good. The
>>> biggest problem ATM is that suspend is badly broken and keeps getting
>>> worse...
>> 
>> I wasn't under the impression suspend had really ever worked.  Such a
>> messy problem to solve.
>
> It never worked reliably for everyone, but with each new release it
> seems to get worse.

2.6.22-rcsomething works better for me than any kernel before it.
It's certainly not only getting worse.

-- 
Måns Rullgård
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fix signalfd interaction with thread-private signals

[Linus Torvalds]

On Fri, 22 Jun 2007, Benjamin Herrenschmidt wrote:
> 
> Yeah well... I wanted to have the least surprise path... that is,
> without my patch, signalfd will "sometimes" steal the SIGSEGV depending
> on who races to the lock first

Oh, absolutely. I thought we all agreed that Ben's patch was the right 
thing. It's been merged for some time now (even if it hasn't been merged 
for as long as I initially _thought_, since I had forgotten to apply the 
the first time around ;)

So yes, all my emails have been about the _current_ code. 

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Kernel include files

[Joerg Schilling]

[EMAIL PROTECTED] wrote:

> On Fri, 22 Jun 2007, Joerg Schilling wrote:
>
> > Is there some hope that at least the Linux kernel interface definition 
> > files and
> > everything recursively included from these files will be rewritten in 
> > vanilla
> > ANSI C?
>
> this has been discussed many times and the answer is that the kernel is 
> not gong to change it's side of things to ANSI C.
>
> that doesn't mean that one of the many projects out there to create 
> seperate interface headers won't do this.

The main problems are not really hard to fix..

-   Most problems eem to be related to the fact that Linux does not
use C-99 based types in the kernel and the related type definitions 
are not written in plain C. This is something that should be fixed
with a source consolidation program or by defining aliases to 
C-99 types in case the compiler is not GCC.

-   Other problems are caused by additional tag definitions that could
be disabled in case of a non-GCC compile.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

> Are you seriously suggesting that the Linux kernel source contain code with
> various different licenses

It already does.  All the way from permissive Free Software licenses
to GPLv2-incompatible non-Free Software licenses.

> Over time, the code will get so combined and interwoven that the
> intersection of all permitted licenses would soon apply to
> effectively the entire kernel.

If you don't keep things clearly separate, yes.

I was honestly thinking more along the lines of ZFS as a separate
driver than about your bringing GPLv3 code into the core of the
kernel.

But then, it would be your call either way.

This option of mutual cooperation wouldn't work for either party if
you're not willing to cooperate, and that's what I believe makes it
fair.

Now, if you guys can't recognize a goodwill gesture when you see one,
and prefer to live in the paranoid beliefs that "those evil FSFers are
trying to force me into a situation in which they'll then be able to
steal my code", that's really up to you.  Don't try to shift the blame
of your decisions onto the FSF.

One thing is missing the spirit of the GPL and using it to serve a
different purpose, without realizing it doesn't provide you with
exactly what you want (tivoization, for example); another completely
different is to try to put it as FSF's fault that clarifications and
amendments are desirable to ensure the ability for authors to enforce
the intent of the GPL.

> Unless, that is, GPLv3 makes itself compatible with GPlv2.

Hey, but that was precisely what I was suggesting!  Except that it
wasn't with GPLv2 alone, because this doesn't work.  Each copyleft
license insists that it be *the* license.  So, in order to be able to
combine two copyleft licenses, you need mutual compatibility
provisions in both.  Which is what I was proposing.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] alpha: fix alignment problem in csum_ipv6_magic()

[Andrew Morton]

> On Sun, 17 Jun 2007 01:20:20 +0400 Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> Hopefully this fixes http://bugzilla.kernel.org/show_bug.cgi?id=8635
> 
> The struct in6_addr passed to csum_ipv6_magic() is 4 byte aligned,
> so we can't use the regular 64-bit loads.
> Since the cost of handling of 4 byte and 1 byte aligned 64-bit data is
> roughly the same, this code can cope with any src/dst [mis]alignment.
> 
> Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
> 
> Ivan.
> 
> --- 2.6.22-rc4/arch/alpha/lib/ev6-csum_ipv6_magic.S   Sun Feb  4 21:44:54 2007
> +++ linux/arch/alpha/lib/ev6-csum_ipv6_magic.SSun Jun 17 00:41:53 2007
> @@ -46,6 +46,10 @@
>   * add the 3 low ushorts together, generating a uint
>   * a final add of the 2 lower ushorts
>   * truncating the result.
> + *
> + * Misalignment handling added by Ivan Kokshaysky <[EMAIL PROTECTED]>
> + * The cost is 16 instructions (~8 cycles), including two extra loads which
> + * may cause additional delay in rare cases (load-load replay traps).
>   */
>  
>   .globl csum_ipv6_magic
> @@ -55,25 +59,45 @@
>  csum_ipv6_magic:
>   .prologue 0
>  
> - ldq $0,0($16)   # L : Latency: 3
> + ldq_u   $0,0($16)   # L : Latency: 3
>   inslh   $18,7,$4# U : 00AABBCC
> - ldq $1,8($16)   # L : Latency: 3
> + ldq_u   $1,8($16)   # L : Latency: 3
>   sll $19,8,$7# U : U L U L : 0x 00aabb00
>  
> + and $16,7,$6# E : src misalignment
> + ldq_u   $5,15($16)  # L : Latency: 3
>   zapnot  $20,15,$20  # U : zero extend incoming csum
> - ldq $2,0($17)   # L : Latency: 3
> - sll $19,24,$19  # U : U L L U : 0x00aa bb00
> - inswl   $18,3,$18   # U : 00CCDD00
> + ldq_u   $2,0($17)   # L : U L U L : Latency: 3
> +
> + extql   $0,$6,$0# U :
> + extqh   $1,$6,$22   # U :
> + ldq_u   $3,8($17)   # L : Latency: 3
> + sll $19,24,$19  # U : U U L U : 0x00aa bb00
> +
> + cmoveq  $6,$31,$22  # E : src aligned?
> + ldq_u   $23,15($17) # L : Latency: 3
> + or  $18,$4,$18  # E : 00CCDDAABBCC
> + extql   $1,$6,$1# U : U L L U :
>  
> - ldq $3,8($17)   # L : Latency: 3
> - bis $18,$4,$18  # E : 00CCDDAABBCC
> + or  $0,$22,$0   # E : 1st src word complete
> + extqh   $5,$6,$5# U :
>   addl$19,$7,$19  # E : bbaabb00
> - nop # E : U L U L
> + and $17,7,$6# E : L U L U : dst misalignment
>  
> + inswl   $18,3,$18   # U : 00CCDD00
> + or  $1,$5,$1# E : 2nd src word complete
> + extql   $2,$6,$2# U :
> + extqh   $3,$6,$22   # U : U L U U :
> +
> + cmoveq  $6,$31,$22  # E : dst aligned?
> + extql   $3,$6,$3# U :
>   addq$20,$0,$20  # E : begin summing the words
> + extqh   $23,$6,$23  # U : L U L U :
> +
>   srl $18,16,$4   # U : 00CCDDAA
> + or  $2,$22,$2   # E : 1st dst word complete
>   zap $19,0x3,$19 # U : bbaa
> - nop # E : L U U L
> + or  $3,$23,$3   # E : U L U L : 2nd dst word complete
>  
>   cmpult  $20,$0,$0   # E :
>   addq$20,$1,$20  # E :
> --- 2.6.22-rc4/arch/alpha/lib/csum_ipv6_magic.S   Sun Feb  4 21:44:54 2007
> +++ linux/arch/alpha/lib/csum_ipv6_magic.SSun Jun 17 00:29:28 2007
> @@ -7,6 +7,9 @@
>   *__u32 len,
>   *unsigned short proto,
>   *unsigned int csum);
> + *
> + * Misalignment handling (which costs 16 instructions / 8 cycles) 
> + * added by Ivan Kokshaysky <[EMAIL PROTECTED]>
>   */
>  
>   .globl csum_ipv6_magic
> @@ -16,37 +19,57 @@
>  csum_ipv6_magic:
>   .prologue 0
>  
> - ldq $0,0($16)   # e0: load src & dst addr words
> + ldq_u   $0,0($16)   # e0: load src & dst addr words
>   zapnot  $20,15,$20  # .. e1 : zero extend incoming csum
>   extqh   $18,1,$4# e0: byte swap len & proto while we wait
> - ldq $1,8($16)   # .. e1 :
> + ldq_u   $21,7($16)  # .. e1 : handle misalignment
>  
>   extbl   $18,1,$5# e0:
> - ldq $2,0($17)   # .. e1 :
> + ldq_u   $1,8($16)   # .. e1 :
>   extbl   $18,2,$6# e0:
> - ldq $3,8($17)   # .. e1 :
> + ldq_u   $22,15($16) # .. e1 :
>  
>   extbl   $18,3,$18   # e0:
> + ldq_u   $2,0($17)   # .. e1 :
>   sra $4,32,$4# e0:
> + ldq_u   $23,7($17)  # .. e1 :
> +
> + extql   $0,$16,$0   # e0:
> + ldq_u   $3,8($17)   # .. e1 :
> + extqh   $21,$16,$21 # e0:
> + ldq_u   $24,15($17) # .. e1 :
> +
>   sll $5,16,$5# e0:
> +   

Re: Writing a driver for a legacy serial device

[Arnd Bergmann]

On Thursday 21 June 2007, Jean Delvare wrote:
> I2C bus drivers have to be implemented in the kernel, so user-space
> isn't an option for me.

Well, you could have an i2c_algorithm that exports a character device
node to user space, and then have a trivial user application that
simply relays between that and the serial port.

It's probably not much different to what you have in the end though.

Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Please release a stable kernel Linux 3.0

[david]

On Fri, 22 Jun 2007, Jan Engelhardt wrote:


On Jun 22 2007 00:29, Jesper Juhl wrote:

On 21/06/07, Zoltán HUBERT <[EMAIL PROTECTED]> wrote:
[snip]

All people who might read this know that traditionally
stable releases are even numbered and development branches
are odd numbered. This changed during late develoment of
2.6, according to my analysis because of the "invention" of
GIT which was itself necessary because of BitKeeper (insert
old flame-wars here) and which allowed very dynamic
develoment.

[...]
I myself have argued that we should be focusing more on stability and
regression fixing, but I'm not so sure that a 2.6.7 devel branch would
solve this. In general the 2.6.x.y -stable kernels seem to be doing
the job pretty good.


For my part, I think the 2.6. did not go as well as the 2.6.,
beginning with x=16.


you misunderstood the even/odd it was never 2.x.y with y odd/even being 
stable / development, it was the x being even/odd to indicate stable / 
development.


all 2.6.x are stable, all 2.5.x were development.

David Lang

Re: Fix signalfd interaction with thread-private signals

[Benjamin Herrenschmidt]

On Thu, 2007-06-21 at 22:58 +0400, Oleg Nesterov wrote:
> 
> > No "stealing". No signalfd, no *nothing*. Just normal signal
> behaviour.
> 
> _Another_ thread could steal SIGSEGV via read(signalfd) without Ben's patch.
> This is what Ben and Davide are worried about. I think we should not worry,
> we have the same situation if this "another" thread does
> 
> for (;;)
> signal(SIGSEGV, SIG_IGN);
> 
> do_sigaction() does rm_from_queue_full().

Yeah well... I wanted to have the least surprise path... that is,
without my patch, signalfd will "sometimes" steal the SIGSEGV depending
on who races to the lock first, thus causing the target thread to
re-execute the faulting instruction and taking another SIGSEGV, and
sometimes not. It's bad from both the faulting thread point of view and
the signalfd use who gets signals "sometimes" without any guarantee.

I like the current code that at least implement a precise semantic for
all thread local signals -> they are only ever delivered to that thread,
period. If you really want to do funky things from outside, you can
still do ptrace ;-)

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Please release a stable kernel Linux 3.0

[Jan Engelhardt]

On Jun 22 2007 00:29, Jesper Juhl wrote:
> On 21/06/07, Zoltán HUBERT <[EMAIL PROTECTED]> wrote:
> [snip]
>> All people who might read this know that traditionally
>> stable releases are even numbered and development branches
>> are odd numbered. This changed during late develoment of
>> 2.6, according to my analysis because of the "invention" of
>> GIT which was itself necessary because of BitKeeper (insert
>> old flame-wars here) and which allowed very dynamic
>> develoment.
>[...]
> I myself have argued that we should be focusing more on stability and
> regression fixing, but I'm not so sure that a 2.6.7 devel branch would
> solve this. In general the 2.6.x.y -stable kernels seem to be doing
> the job pretty good.

For my part, I think the 2.6. did not go as well as the 2.6.,
beginning with x=16.

>> Why on earth call "kernel object" things that are "kernel modules"
>> ? And that every person calls "modules" and not "objects" ? I know
>> I know, in UNIX dynamic libraries are .so "shared objects", so
>> what ? A "module" is a "module" and NOT an "object", call a cat a
>> cat.
>>
> It sure is an object, it's even called object code. I think the name
> suits just fine. In any case, it's just a name.

Back in the 2.4 days and e.g. on Solaris (still) today, a kernel
object file is [can be] a kernel module. Under Linux, this is not the
case anymore since 2.6.x when kbuild started to postprocess modules
(creating these nice .mod.c and .mod.o files and the benefits
associated with it).



Jan
--