Hello Emilio,
please apply the following patch: "cpu_data" is defined in a header files of
architectures.
In some architecture, the #define cpu_data is not a "macro-function", so the
compiler will substitute the identifier with probably something wrong.
--- a/drivers/clk/sunxi/clk-sunxi.c
+++
Hello Emilio,
please apply the following patch: cpu_data is defined in a header files of
architectures.
In some architecture, the #define cpu_data is not a macro-function, so the
compiler will substitute the identifier with probably something wrong.
--- a/drivers/clk/sunxi/clk-sunxi.c
+++
I've a kernel bug since few days, but I've not yet had time to bisect.
The output is in:
http://cateee.net/kernel/dsc00169.jpg
ciao
cate
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
I've a kernel bug since few days, but I've not yet had time to bisect.
The output is in:
http://cateee.net/kernel/dsc00169.jpg
ciao
cate
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
And to demostrate that Linus is not the only person
with this view, I copy some paragraphs from C99 rationale
(you can find standard, rationale and other documents
in http://clc-wiki.net/wiki/C_standardisation:ISO )
Page 75 of C99 rationale:
Type qualifiers were introduced in part to provide
And to demostrate that Linus is not the only person
with this view, I copy some paragraphs from C99 rationale
(you can find standard, rationale and other documents
in http://clc-wiki.net/wiki/C_standardisation:ISO )
Page 75 of C99 rationale:
Type qualifiers were introduced in part to provide
Linus Torvalds wrote:
>
> On Thu, 17 Jan 2008, David Schwartz wrote:
>>> "const" has nothing to do with "logical state". It has one meaning, and
>>> one meaning only: the compiler should complain if that particular type is
>>> used to do a write access.
>> Right, exactly.
>
> So why do you
Linus Torvalds wrote:
On Thu, 17 Jan 2008, David Schwartz wrote:
const has nothing to do with logical state. It has one meaning, and
one meaning only: the compiler should complain if that particular type is
used to do a write access.
Right, exactly.
So why do you complain?
kfree()
Andrew Morton wrote:
> On Thu, 06 Dec 2007 09:21:53 +0100 Giacomo Catenazzi <[EMAIL PROTECTED]>
> wrote:
>
>> Andrew Morton wrote:
>>> On Mon, 3 Dec 2007 19:00:25 GMT Linux Kernel Mailing List
>>> wrote:
>>>
>>>> Gitweb:
>&
Andrew Morton wrote:
> On Mon, 3 Dec 2007 19:00:25 GMT Linux Kernel Mailing List
> wrote:
>
>> Gitweb:
>> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
>> Commit: 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
>>
Andrew Morton wrote:
On Mon, 3 Dec 2007 19:00:25 GMT Linux Kernel Mailing List
linux-kernel@vger.kernel.org wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
Commit:
Andrew Morton wrote:
On Thu, 06 Dec 2007 09:21:53 +0100 Giacomo Catenazzi [EMAIL PROTECTED]
wrote:
Andrew Morton wrote:
On Mon, 3 Dec 2007 19:00:25 GMT Linux Kernel Mailing List
linux-kernel@vger.kernel.org wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds
Adrian Bunk wrote:
On Sun, Nov 04, 2007 at 05:19:45PM +0100, Giacomo Catenazzi wrote:
Adrian Bunk wrote:
On Sun, Nov 04, 2007 at 02:31:33AM -0800, David Miller wrote:
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Sun, 4 Nov 2007 11:04:29 +0100
* Adrian Bunk <[EMAIL PROTECTED]> wr
Adrian Bunk wrote:
On Sun, Nov 04, 2007 at 02:31:33AM -0800, David Miller wrote:
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Sun, 4 Nov 2007 11:04:29 +0100
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
I also have CFLAGS set on some computers in my environments since for
packages using GNU
Adrian Bunk wrote:
On Sun, Nov 04, 2007 at 02:31:33AM -0800, David Miller wrote:
From: Ingo Molnar [EMAIL PROTECTED]
Date: Sun, 4 Nov 2007 11:04:29 +0100
* Adrian Bunk [EMAIL PROTECTED] wrote:
I also have CFLAGS set on some computers in my environments since for
packages using GNU autoconf
Adrian Bunk wrote:
On Sun, Nov 04, 2007 at 05:19:45PM +0100, Giacomo Catenazzi wrote:
Adrian Bunk wrote:
On Sun, Nov 04, 2007 at 02:31:33AM -0800, David Miller wrote:
From: Ingo Molnar [EMAIL PROTECTED]
Date: Sun, 4 Nov 2007 11:04:29 +0100
* Adrian Bunk [EMAIL PROTECTED] wrote:
I also have
Rik van Riel wrote:
> On Tue, 16 Oct 2007 22:09:04 +0200 (CEST)
> Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> On Oct 16 2007 13:06, Mark Gross wrote:
>>> base function:
>>> Starting from a stock distro (FC, Ubuntu, OpenSuSE...) and put down a
>>> kernel.org tree and automatically create a .config
Rik van Riel wrote:
On Tue, 16 Oct 2007 22:09:04 +0200 (CEST)
Jan Engelhardt [EMAIL PROTECTED] wrote:
On Oct 16 2007 13:06, Mark Gross wrote:
base function:
Starting from a stock distro (FC, Ubuntu, OpenSuSE...) and put down a
kernel.org tree and automatically create a .config with all the
Andrew Morton wrote:
> On Tue, 23 Oct 2007 21:04:20 +0200 Giacomo Catenazzi <[EMAIL PROTECTED]>
> wrote:
>
>> Oct 23 20:20:05 catee kernel: BUG: unable to handle kernel paging request at
>> virtual address 92184900
>
> Is this still happening in the latest Li
Andrew Morton wrote:
On Tue, 23 Oct 2007 21:04:20 +0200 Giacomo Catenazzi [EMAIL PROTECTED]
wrote:
Oct 23 20:20:05 catee kernel: BUG: unable to handle kernel paging request at
virtual address 92184900
Is this still happening in the latest Linus tree?
If so, please send some more oops
Hello,
I've build a python script (consisting on short 4 modules) to
build a hardware database fomr kernel sources, with includes:
type of hardware, hardware information, kernel CONFIG and
the kernel file where such hardware was described.
Actually I can detect nearly 6000 probes (and easily
Hello,
I've build a python script (consisting on short 4 modules) to
build a hardware database fomr kernel sources, with includes:
type of hardware, hardware information, kernel CONFIG and
the kernel file where such hardware was described.
Actually I can detect nearly 6000 probes (and easily
Linus Torvalds wrote:
> The gcc lists seem to often get to the point where people quote the
> standard, and that's that. In that environment, the paper standard (that
> hass *nothing* to do with reality) trumps any other argument. "What we do
> is _allowed_ by the standard" seems to be a good
Linus Torvalds wrote:
The gcc lists seem to often get to the point where people quote the
standard, and that's that. In that environment, the paper standard (that
hass *nothing* to do with reality) trumps any other argument. What we do
is _allowed_ by the standard seems to be a good
On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at virtual
address 3d15b925
In last git, I see the following BUGs in various programs. It seems
reproducible, but sometime I've hard lookup on poweroff.
ciao
cate
vivi: open called (minor=0)
vivi: close called
On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at virtual
address 3d15b925
In last git, I see the following BUGs in various programs. It seems
reproducible, but sometime I've hard lookup on poweroff.
ciao
cate
vivi: open called (minor=0)
vivi: close called
Thomas Fricaccia wrote:
> Some well-respected contributors have taken exception my amplification
> of Crispin Cowan's point about the patch that closes LSM.
>
> Crispin Cowan <[EMAIL PROTECTED]> wrote:
>> * It prevents enterprise users, and in fact anyone who isn't
>> comfortable
Jan Engelhardt wrote:
> I do have a pseudo LSM called "multiadm" at
> http://freshmeat.net/p/multiadm/ , quoting:
> Policy is dead simple since it is based on UIDs. The UID ranges can be
> set on module load time or during runtime (sysfs params). This LSM is
> basically grants extra rights
Jan Engelhardt wrote:
I do have a pseudo LSM called multiadm at
http://freshmeat.net/p/multiadm/ , quoting:
Policy is dead simple since it is based on UIDs. The UID ranges can be
set on module load time or during runtime (sysfs params). This LSM is
basically grants extra rights unlike
Thomas Fricaccia wrote:
Some well-respected contributors have taken exception my amplification
of Crispin Cowan's point about the patch that closes LSM.
Crispin Cowan [EMAIL PROTECTED] wrote:
* It prevents enterprise users, and in fact anyone who isn't
comfortable compiling their
Sam Ravnborg wrote:
> On Mon, Oct 15, 2007 at 10:04:11AM -0700, Mark Gross wrote:
>> On Sun, Oct 14, 2007 at 07:01:28PM -0400, Rik van Riel wrote:
>>> The kernel newbies community often gets inquiries from CS students who
>>> need a project for their studies and would like to do something with
>>>
Sam Ravnborg wrote:
On Mon, Oct 15, 2007 at 10:04:11AM -0700, Mark Gross wrote:
On Sun, Oct 14, 2007 at 07:01:28PM -0400, Rik van Riel wrote:
The kernel newbies community often gets inquiries from CS students who
need a project for their studies and would like to do something with
the Linux
Mike Galbraith wrote:
> On Fri, 2007-10-12 at 23:31 +0200, Sam Ravnborg wrote:
>> On Fri, Oct 12, 2007 at 06:48:58AM +0200, Mike Galbraith wrote:
>>> Greetings,
>>>
>>> Freshly pulled 2.6.23.git failed to build:
>>>
>>> make[1]: *** No rule to make target `arch/x86/kernel/asm-offsets.c', needed
Mike Galbraith wrote:
On Fri, 2007-10-12 at 23:31 +0200, Sam Ravnborg wrote:
On Fri, Oct 12, 2007 at 06:48:58AM +0200, Mike Galbraith wrote:
Greetings,
Freshly pulled 2.6.23.git failed to build:
make[1]: *** No rule to make target `arch/x86/kernel/asm-offsets.c', needed
by
Adrian Bunk wrote:
>
> BTW: I'm currently trying without success to understand why the
> drivers/infiniband/{hw/amso1100,ulp/srp}/Kbuild files are not
> named "Makefile".
or the inverse ;-) Why all Makefiles (but the top level one ) are not
named Kbuild, considering that they are not
Adrian Bunk wrote:
BTW: I'm currently trying without success to understand why the
drivers/infiniband/{hw/amso1100,ulp/srp}/Kbuild files are not
named Makefile.
or the inverse ;-) Why all Makefiles (but the top level one ) are not
named Kbuild, considering that they are not valid
gaged!
The last git tree give me no errors.
patch in Message-ID: <[EMAIL PROTECTED]>
Tested-By: Giacomo Catenazzi <[EMAIL PROTECTED]>
ciao
cate
-
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/
, buffer
, data , len 36
Jul 19 08:22:23 catee kernel: cdb: 12 00 00 00 24 00 00 00 00 00 00 00
00 00 00 00
Jul 19 08:22:27 catee kernel: ttyS1: LSR safety check engaged!
The last git tree give me no errors.
patch in Message-ID: [EMAIL PROTECTED]
Tested-By: Giacomo Catenazzi
Linus Torvalds wrote:
>
> On Tue, 17 Jul 2007, Bartlomiej Zolnierkiewicz wrote:
>> ide-disk driver and type 2 (REQ_TYPE_BLOCK_PC) requests don't mix well
>>
>> Probably some dumb application is sending packet commands without
>> checking the device type...
>
> Ok, we should definitely try to
Linus Torvalds wrote:
On Tue, 17 Jul 2007, Bartlomiej Zolnierkiewicz wrote:
ide-disk driver and type 2 (REQ_TYPE_BLOCK_PC) requests don't mix well
Probably some dumb application is sending packet commands without
checking the device type...
Ok, we should definitely try to just translate
Hello,
last git changes to git give me the following error (repead very quickly):
sector 14657019, nr/cmr 0/0
bio f7b59280, biotail f7b59280, buffer 000, date 000, len 36
ide_do_rw_disk-bad command: dev hda: type 2, flags 104c8
[note: manually copied]
I tried bisect:
[EMAIL
Hello,
last git changes to git give me the following error (repead very quickly):
sector 14657019, nr/cmr 0/0
bio f7b59280, biotail f7b59280, buffer 000, date 000, len 36
ide_do_rw_disk-bad command: dev hda: type 2, flags 104c8
[note: manually copied]
I tried bisect:
[EMAIL
"Eric S. Raymond" wrote:
>
> Giacomo A. Catenazzi <[EMAIL PROTECTED]>:
> > My proposal is instaed of complain about configuration violatation,
> > you just wrote the possible correct configuration and prompt user to
> > select the correct configuration.
> > In the case you cite, e.g. oldconfig
Eric S. Raymond wrote:
Giacomo A. Catenazzi [EMAIL PROTECTED]:
My proposal is instaed of complain about configuration violatation,
you just wrote the possible correct configuration and prompt user to
select the correct configuration.
In the case you cite, e.g. oldconfig shoud prompt:
Alan Cox wrote:
>
> > Well, would it be possible to create some module under LGPL, and then
> > have included it into the kernel? Maybe it needs to maintain the LGPL
> > version out of the kernel, and transform a copy to the GPL before
> > submitting?
>
> There is kernel code under a whole
Alan Cox wrote:
Well, would it be possible to create some module under LGPL, and then
have included it into the kernel? Maybe it needs to maintain the LGPL
version out of the kernel, and transform a copy to the GPL before
submitting?
There is kernel code under a whole variety of
Hello.
After an user of us (debian) complained about the "xxx uses
obsolete /proc/pci interface",
I noticed that in 2.2.19, drivers/pci/oldproc.c, line 1042
kernel still writes:
> printk(KERN_INFO "%s uses obsolete /proc/pci interface\n",
Now 2.3/2.4 this interface is still available and no
Hello.
After an user of us (debian) complained about the "xxx uses
obsolete /proc/pci interface",
I noticed that in 2.2.19, drivers/pci/oldproc.c, line 1042
kernel still writes:
printk(KERN_INFO "%s uses obsolete /proc/pci interface\n",
Now 2.3/2.4 this interface is still available and no
"Albert D. Cahalan" wrote:
>
> > * All three interfaces do progressive disclosure -- the user only sees
> > questions he/she needs to answer (no more hundreds of greyed-out menu
> > entries for irrelevant drivers!).
>
> Well, that sucks. The greyed-out menu entries were the only good
>
"Albert D. Cahalan" wrote:
* All three interfaces do progressive disclosure -- the user only sees
questions he/she needs to answer (no more hundreds of greyed-out menu
entries for irrelevant drivers!).
Well, that sucks. The greyed-out menu entries were the only good
thing about
Andrzej Krzysztofowicz wrote:
>
> "Giacomo Catenazzi wrote:"
> > Johan Adolfsson wrote:
> > >
> > > Having the help close to the config sounds like a good idea
> > > from a maintenance point of view.
> >
> > But in 2.5.x the
Johan Adolfsson wrote:
>
> > This change is too big for 2.4 kernel.
>
> It doesnt look that big to mee, so here it is for everyones consideration
> (the mailprogram probably screws up tabs etc. but you get the idea,
> I apologise if posting patches like this is the wrong way)
>
> The normal
Johan Adolfsson wrote:
>
> > - IIRC there is only few ARCH specific configuration, thus we
> > don't
> > reduce the size of che Configure.help
> > Note that the arch/config.in have to much configuration item
> > (but they repeat in (nearly) all arch/config.in files, thus
> > you
> >
[EMAIL PROTECTED] wrote:
>
> > This was already discussed on kbuild list.
> > It is better to have only 1 Configure.help. This help
> > translation of the file and help busy developers.
> > They should not rewrite texts in every Configure.help.
>
> I can't see that 1 file makes it easier.
> The
[EMAIL PROTECTED] wrote:
>
> I went ahead and implemented the change last night anyway and I
> will submit the patches and see if it will be accepted or not.
> The idea is that it first check in arch/$ARCH/Configure.help
> and if the file or the help is not found there,
> check
[EMAIL PROTECTED] wrote:
I went ahead and implemented the change last night anyway and I
will submit the patches and see if it will be accepted or not.
The idea is that it first check in arch/$ARCH/Configure.help
and if the file or the help is not found there,
check
[EMAIL PROTECTED] wrote:
This was already discussed on kbuild list.
It is better to have only 1 Configure.help. This help
translation of the file and help busy developers.
They should not rewrite texts in every Configure.help.
I can't see that 1 file makes it easier.
The same help
Johan Adolfsson wrote:
- IIRC there is only few ARCH specific configuration, thus we
don't
reduce the size of che Configure.help
Note that the arch/config.in have to much configuration item
(but they repeat in (nearly) all arch/config.in files, thus
you
should count only
Johan Adolfsson wrote:
This change is too big for 2.4 kernel.
It doesnt look that big to mee, so here it is for everyones consideration
(the mailprogram probably screws up tabs etc. but you get the idea,
I apologise if posting patches like this is the wrong way)
The normal
Andrzej Krzysztofowicz wrote:
"Giacomo Catenazzi wrote:"
Johan Adolfsson wrote:
Having the help close to the config sounds like a good idea
from a maintenance point of view.
But in 2.5.x the config.in are centralized, thus also
Configure.help sould be c
"Hen, Shmulik" wrote:
>
> Just some general questions:
>
> 1) Is there anywhere a list that describes what is intended to be in 2.5.x ?
General/Big changes are discussed in:
http://lwn.net/2001/0329/a/kernel-summit-agenda.php3
> 2) Are there any early releases of 2.5.x ?
> 3) Are the things
"Hen, Shmulik" wrote:
Just some general questions:
1) Is there anywhere a list that describes what is intended to be in 2.5.x ?
General/Big changes are discussed in:
http://lwn.net/2001/0329/a/kernel-summit-agenda.php3
2) Are there any early releases of 2.5.x ?
3) Are the things for
Studierende der Universitaet des Saarlandes wrote:
>
> I have 2 ideas:
> * glibc corrupted
> * did you downgrade the cpu?
These happen frequently to me (when compiling and installing a
new glibc)
But in this case you would have other messages (IIRC something
like
respawn too fast).
Thus the
Studierende der Universitaet des Saarlandes wrote:
I have 2 ideas:
* glibc corrupted
* did you downgrade the cpu?
These happen frequently to me (when compiling and installing a
new glibc)
But in this case you would have other messages (IIRC something
like
respawn too fast).
Thus the problem
Hello!
I was writing a bug report (parport slow, resources
problems?),
when I tried something strange and OOPS.
The original report is included in the last part of this
email.
After writing the report, I disabled parport resources in BIOS
and I maked:
cate3:~# modprobe parport_pc
Unable to
Hello!
I was writing a bug report (parport slow, resources
problems?),
when I tried something strange and OOPS.
The original report is included in the last part of this
email.
After writing the report, I disabled parport resources in BIOS
and I maked:
cate3:~# modprobe parport_pc
Unable to
Hello!
I just release a new verion of kernel autoconfig.
The kernel autoconfiguration utility will help user to detect and
configure the kernel. The detection is soft, thus no hangs!
It is still in test phase, thus now it prints only the proposed
configuration. To change real configurations,
Hello!
I just release a new verion of kernel autoconfig.
The kernel autoconfiguration utility will help user to detect and
configure the kernel. The detection is soft, thus no hangs!
It is still in test phase, thus now it prints only the proposed
configuration. To change real configurations,
[EMAIL PROTECTED] wrote:
>
> Sanjeev Wrote:
> I am not able to mount my floppy drive. When I try to mount it gives me the
> following error
> 'mount: /dev/fd0 has wrong major or minor number'
did you update the modutils?
giacomo
-
To unsubscribe from this list: send the line
[EMAIL PROTECTED] wrote:
Sanjeev Wrote:
I am not able to mount my floppy drive. When I try to mount it gives me the
following error
'mount: /dev/fd0 has wrong major or minor number'
did you update the modutils?
giacomo
-
To unsubscribe from this list: send the line "unsubscribe
Here a valid configuration (no AGP, but all DRM set)
compiling [2.4.0]:
r128_cce.c: In function `r128_cce_init_ring_buffer':
r128_cce.c:339: structure has no member named `agp'
r128_cce.c:333: warning: `ring_start' might be used uninitialized in
this function
r128_cce.c: In function
Here a valid configuration (no AGP, but all DRM set)
compiling [2.4.0]:
r128_cce.c: In function `r128_cce_init_ring_buffer':
r128_cce.c:339: structure has no member named `agp'
r128_cce.c:333: warning: `ring_start' might be used uninitialized in
this function
r128_cce.c: In function
"J . A . Magallon" wrote:
>
> On 2001.01.02 Giacomo A. Catenazzi wrote:
> > Hello!
> >
> > When working in cpu autoconfiguration I found some problems:
> >
> > I have to identify this processor:
> > Vendor: Intel
> > Family: 6
> > Model: 8
> > Is it a "Pentium III (Coppermine)"
"J . A . Magallon" wrote:
On 2001.01.02 Giacomo A. Catenazzi wrote:
Hello!
When working in cpu autoconfiguration I found some problems:
I have to identify this processor:
Vendor: Intel
Family: 6
Model: 8
Is it a "Pentium III (Coppermine)" (setup.c:1709)
or a "Celeron
Linus Torvalds wrote:
>
> On Mon, 25 Dec 2000, Alan Cox wrote:
>
> > > One thing we _could_ potentially do is to simplify the CPU selection a
> > > bit, and make it a two-stage process. Basically have a
> > >
> > > bool "Optimize for current CPU" CONFIG_CPU_CURRENT
> > >
> > > which most
Linus Torvalds wrote:
On Mon, 25 Dec 2000, Alan Cox wrote:
One thing we _could_ potentially do is to simplify the CPU selection a
bit, and make it a two-stage process. Basically have a
bool "Optimize for current CPU" CONFIG_CPU_CURRENT
which most people who just want to
On my box, with heavy load I saw:
spurious 8259A interrupt: IRQ7.
Newer seen this message before.
Linux (2.4.0.11.4) or my old slow box ?
giacomo
My dmesg
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @
"H. Peter Anvin" wrote:
>
>
> Good question. The whole thing makes me nervous... in fact, perhaps we
> should really consider using the BIOS INT 15h interrupt to enter
> protected mode?
>
Maybe it is better to try with INT15 AX=2400 (Enable A20 gate).
INT 15-2400 enable A20
INT 15-2401
"H. Peter Anvin" wrote:
Good question. The whole thing makes me nervous... in fact, perhaps we
should really consider using the BIOS INT 15h interrupt to enter
protected mode?
Maybe it is better to try with INT15 AX=2400 (Enable A20 gate).
INT 15-2400 enable A20
INT 15-2401 disable
On my box, with heavy load I saw:
spurious 8259A interrupt: IRQ7.
Newer seen this message before.
Linux (2.4.0.11.4) or my old slow box ?
giacomo
My dmesg
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @
Amit D Chaudhary wrote:
>
> Hi,
>
> When trying to create a patch with linux 2.2.17 sources, I found the
> following files to be of size 0 in linux-2.2.17.tar.gz.
> linux/include/linux/dasd.h
> linux/include/linux/coda_opstats.h
>
> Since the file is the most latest in the kernel/v2.2
Amit D Chaudhary wrote:
Hi,
When trying to create a patch with linux 2.2.17 sources, I found the
following files to be of size 0 in linux-2.2.17.tar.gz.
linux/include/linux/dasd.h
linux/include/linux/coda_opstats.h
Since the file is the most latest in the kernel/v2.2 directory,
On Wed, Sep 13, 2000 at 02:15:58AM -0700, Daniel Quinlan wrote:
> Proposal:
>
> 1. Developers submit all Linux kernel patches to [EMAIL PROTECTED]
>(not in place yet, so don't start sending patches).
@vger.kernel.org
> 2. Each patch will conform to a standardized, but simple, text
On Wed, Sep 13, 2000 at 02:15:58AM -0700, Daniel Quinlan wrote:
Proposal:
1. Developers submit all Linux kernel patches to [EMAIL PROTECTED]
(not in place yet, so don't start sending patches).
@vger.kernel.org
2. Each patch will conform to a standardized, but simple, text format,
84 matches
Mail list logo
