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
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
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
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.
(
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
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,
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
===
---
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
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
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
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
===
---
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
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
> -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,
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
[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
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
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
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.
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
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
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
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
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]>
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
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
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
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
> >> >
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
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
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
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
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
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
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
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
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
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
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
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
> >> >
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
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
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
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
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
>
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
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.
--
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
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
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
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
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
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:
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
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
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
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.
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
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
> 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
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
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
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
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
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,
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
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
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
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
[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
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
> 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
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
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
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,
>
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,
1 - 100 of 979 matches
Mail list logo
