Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
> On 1/18/07, Russell King <[EMAIL PROTECTED]> wrote:
>> On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
>> > 2. Set command_line as __initdata.
>> You can't.
>>
>> > -static char command_line[COMMAND_LINE_SIZE];
>> > +static char __initdata
Alon Bar-Lev [EMAIL PROTECTED] wrote:
On 1/18/07, Russell King [EMAIL PROTECTED] wrote:
On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
2. Set command_line as __initdata.
You can't.
-static char command_line[COMMAND_LINE_SIZE];
+static char __initdata
On Tue, 16 Jan 2007, Arjan van de Ven wrote:
> On Tue, 2007-01-16 at 21:26 +0100, Bodo Eggert wrote:
> > Helge Hafting <[EMAIL PROTECTED]> wrote:
> > > Michael Tokarev wrote:
> > >> But seriously - what about just disallowing non-O_DIRECT open
On Tue, 16 Jan 2007, Arjan van de Ven wrote:
On Tue, 2007-01-16 at 21:26 +0100, Bodo Eggert wrote:
Helge Hafting [EMAIL PROTECTED] wrote:
Michael Tokarev wrote:
But seriously - what about just disallowing non-O_DIRECT opens together
with O_DIRECT ones ?
Please do not create
Helge Hafting <[EMAIL PROTECTED]> wrote:
> Michael Tokarev wrote:
>> But seriously - what about just disallowing non-O_DIRECT opens together
>> with O_DIRECT ones ?
>>
> Please do not create a new local DOS attack.
> I open some important file, say /etc/resolv.conf
> with O_DIRECT and just sit
Helge Hafting [EMAIL PROTECTED] wrote:
Michael Tokarev wrote:
But seriously - what about just disallowing non-O_DIRECT opens together
with O_DIRECT ones ?
Please do not create a new local DOS attack.
I open some important file, say /etc/resolv.conf
with O_DIRECT and just sit on the open
Bill Davidsen <[EMAIL PROTECTED]> wrote:
> My point is, that there is code to handle sparse data now, without
> O_DIRECT involved, and if O_DIRECT bypasses that, it's not a problem
> with the idea of O_DIRECT, the kernel has a security problem.
The idea of O_DIRECT is to bypass the pagecache,
On Sat, 13 Jan 2007, Bill Davidsen wrote:
> Bodo Eggert wrote:
>
> > (*) This would allow fadvise_size(), too, which could reduce fragmentation
> > (and give an early warning on full disks) without forcing e.g. fat to
> > zero all blocks. OTOH, fadvise_size() woul
On Sat, 13 Jan 2007, Bill Davidsen wrote:
Bodo Eggert wrote:
(*) This would allow fadvise_size(), too, which could reduce fragmentation
(and give an early warning on full disks) without forcing e.g. fat to
zero all blocks. OTOH, fadvise_size() would allow users to reserve
Bill Davidsen [EMAIL PROTECTED] wrote:
My point is, that there is code to handle sparse data now, without
O_DIRECT involved, and if O_DIRECT bypasses that, it's not a problem
with the idea of O_DIRECT, the kernel has a security problem.
The idea of O_DIRECT is to bypass the pagecache, and the
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Sat, 13 Jan 2007, Michael Tokarev wrote:
>> (No, really - this load isn't entirely synthetic. It's a typical database
>> workload - random I/O all over, on a large file. If it can, it combines
>> several I/Os into one, by requesting more than a
Linus Torvalds [EMAIL PROTECTED] wrote:
On Sat, 13 Jan 2007, Michael Tokarev wrote:
(No, really - this load isn't entirely synthetic. It's a typical database
workload - random I/O all over, on a large file. If it can, it combines
several I/Os into one, by requesting more than a single block
Nick Piggin <[EMAIL PROTECTED]> wrote:
> Aubrey wrote:
>> On 1/11/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
>>> What you _really_ want to do is avoid large mallocs after boot, or use
>>> a CPU with an mmu. I don't think nommu linux was ever intended to be a
>>> simple drop in replacement for a
Nick Piggin [EMAIL PROTECTED] wrote:
Aubrey wrote:
On 1/11/07, Nick Piggin [EMAIL PROTECTED] wrote:
What you _really_ want to do is avoid large mallocs after boot, or use
a CPU with an mmu. I don't think nommu linux was ever intended to be a
simple drop in replacement for a normal unix
Amit Choudhary <[EMAIL PROTECTED]> wrote:
> --- Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>> On Sun, Jan 07, 2007 at 12:46:50AM -0800, Amit Choudhary wrote:
>> > Well, I am not proposing this as a debugging aid. The idea is about correct
>> > programming,
>> atleast
>> > from my view. Ideally,
Amit Choudhary [EMAIL PROTECTED] wrote:
--- Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sun, Jan 07, 2007 at 12:46:50AM -0800, Amit Choudhary wrote:
Well, I am not proposing this as a debugging aid. The idea is about correct
programming,
atleast
from my view. Ideally, if you kfree(x),
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>> > Well, sort of. Samefile without keeping fds open doesn't have any
>> > protection against the tree changing underneath between first
>> > registering a file and later opening it. The inode number is more
>>
>> You only need to keep
Pavel Machek <[EMAIL PROTECTED]> wrote:
>> Another idea is to export the filesystem internal ID as an arbitray
>> length cookie through the extended attribute interface. That could be
>> stored/compared by the filesystem quite efficiently.
>
> How will that work for FAT?
> Or maybe we can
Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
>> +++ a/fs/bad_inode.c
>> -static int return_EIO(void)
>> +static long return_EIO(void)
> What about ops that return loff_t (64 bits) on 32-bit arches and stuff
> it into 2 registers
*If* it uses an additional register for the
Eric Sandeen [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
+++ a/fs/bad_inode.c
-static int return_EIO(void)
+static long return_EIO(void)
What about ops that return loff_t (64 bits) on 32-bit arches and stuff
it into 2 registers
*If* it uses an additional register for the high bits,
Pavel Machek [EMAIL PROTECTED] wrote:
Another idea is to export the filesystem internal ID as an arbitray
length cookie through the extended attribute interface. That could be
stored/compared by the filesystem quite efficiently.
How will that work for FAT?
Or maybe we can relax that
Miklos Szeredi [EMAIL PROTECTED] wrote:
Well, sort of. Samefile without keeping fds open doesn't have any
protection against the tree changing underneath between first
registering a file and later opening it. The inode number is more
You only need to keep one-file-per-hardlink-group
Michael Tokarev <[EMAIL PROTECTED]> wrote:
> I wonder why open() with O_DIRECT (for example) bit set is
> disallowed on a tmpfs (again, for example) filesystem,
> returning EINVAL.
>
> Yes, the question may seems strange a bit, because of two
> somewhat conflicting reasons. First, there's no
Michael Tokarev [EMAIL PROTECTED] wrote:
I wonder why open() with O_DIRECT (for example) bit set is
disallowed on a tmpfs (again, for example) filesystem,
returning EINVAL.
Yes, the question may seems strange a bit, because of two
somewhat conflicting reasons. First, there's no reason to
Dave Jones <[EMAIL PROTECTED]> wrote:
> Shrink the held_lock struct by using bitfields.
> This shrinks task_struct on lockdep enabled kernels by 480 bytes.
> * The following field is used to detect when we cross into an
> * interrupt context:
> */
> - int
David Weinehall <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
>> 1) mcdonald's was not merely serving their coffee "hot," but
>> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
>> will produce third-degree burns almost
David Weinehall [EMAIL PROTECTED] wrote:
On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
1) mcdonald's was not merely serving their coffee hot, but
*scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
will produce third-degree burns almost immediately, and
Dave Jones [EMAIL PROTECTED] wrote:
Shrink the held_lock struct by using bitfields.
This shrinks task_struct on lockdep enabled kernels by 480 bytes.
* The following field is used to detect when we cross into an
* interrupt context:
*/
- int irq_context;
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> On Dec 29 2006 07:57, Daniel Marjamäki wrote:
>> It was my goal to improve the readability. I failed.
>>
>> I personally prefer to use standard functions instead of writing code.
>> In my opinion using standard functions means less code that is easier
Jan Engelhardt [EMAIL PROTECTED] wrote:
On Dec 29 2006 07:57, Daniel Marjamäki wrote:
It was my goal to improve the readability. I failed.
I personally prefer to use standard functions instead of writing code.
In my opinion using standard functions means less code that is easier to
read.
Jörn Engel <[EMAIL PROTECTED]> wrote:
> On Wed, 20 December 2006 20:32:20 +0200, Yakov Lerner wrote:
>> Is it easily possible to build two architectures in
>> the same source tree (so that intermediate fles
>> and resut files do not interfere ) ?
>
> I'd try something like this:
> make O=../foo
Jörn Engel [EMAIL PROTECTED] wrote:
On Wed, 20 December 2006 20:32:20 +0200, Yakov Lerner wrote:
Is it easily possible to build two architectures in
the same source tree (so that intermediate fles
and resut files do not interfere ) ?
I'd try something like this:
make O=../foo ARCH=foo
Alan <[EMAIL PROTECTED]> wrote:
> On Fri, 01 Dec 2006 16:20:46 +0100
> Jan Glauber <[EMAIL PROTECTED]> wrote:
>> Yes, a user can just symlink urandom to prandom and will have a faster
>> generator.
>
>
> More usefully they can use it as an entropy source with an entropy
> daemon to feed it into
Alan [EMAIL PROTECTED] wrote:
On Fri, 01 Dec 2006 16:20:46 +0100
Jan Glauber [EMAIL PROTECTED] wrote:
Yes, a user can just symlink urandom to prandom and will have a faster
generator.
More usefully they can use it as an entropy source with an entropy
daemon to feed it into the standard
Budde, Marco <[EMAIL PROTECTED]> wrote:
> for one of our customers I have to port a Windows driver to
> Linux. Large parts of the driver's backend code consists of
> C++.
>
> How can I compile this code with kbuild? The C++ support
> (I have tested with 2.6.11) of kbuild seems to be incomplete /
Budde, Marco [EMAIL PROTECTED] wrote:
for one of our customers I have to port a Windows driver to
Linux. Large parts of the driver's backend code consists of
C++.
How can I compile this code with kbuild? The C++ support
(I have tested with 2.6.11) of kbuild seems to be incomplete /
not
Erik Mouw <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 25, 2005 at 02:15:13PM -0400, [EMAIL PROTECTED] wrote:
>> For one, if you do "dd if=/dev/zero of=foo" on a ramfs the system
>> will lock up.
>
> "Doctor, it hurts when I do this!" "Well, then don't do that."
> You found a nice case of "Unix,
Erik Mouw [EMAIL PROTECTED] wrote:
On Thu, Aug 25, 2005 at 02:15:13PM -0400, [EMAIL PROTECTED] wrote:
For one, if you do dd if=/dev/zero of=foo on a ramfs the system
will lock up.
Doctor, it hurts when I do this! Well, then don't do that.
You found a nice case of Unix, rope, foot.
It's a
On Sun, 21 Aug 2005, Chris Wedgwood wrote:
> On Sun, Aug 21, 2005 at 09:56:45PM +0200, Bodo Eggert wrote:
> > The parameter value should IMHO be a pointer to a struct {
> > unsigned long long maxspeed; // (with 0 being the magic max. value?)
> > int facility; /* 0=general
On Sun, 21 Aug 2005, Chris Wedgwood wrote:
On Sun, Aug 21, 2005 at 09:56:45PM +0200, Bodo Eggert wrote:
The parameter value should IMHO be a pointer to a struct {
unsigned long long maxspeed; // (with 0 being the magic max. value?)
int facility; /* 0=general speed, 2=general read, 4=read
cHitman <[EMAIL PROTECTED]> wrote:
> This patch implements changing of DVD speed via ioctl() call, like
> CDROM_SELECT_SPEED do. In CDROM_SELECT_SPEED its implementation isn't
> so good (diffirent values of 1x in KB/s, troubles with return value of
> cdrom_select_speed() and other). I defined
cHitman [EMAIL PROTECTED] wrote:
This patch implements changing of DVD speed via ioctl() call, like
CDROM_SELECT_SPEED do. In CDROM_SELECT_SPEED its implementation isn't
so good (diffirent values of 1x in KB/s, troubles with return value of
cdrom_select_speed() and other). I defined
On Fri, 12 Aug 2005, Pete Zaitcev wrote:
> On Fri, 12 Aug 2005 12:49:28 +0200, Bodo Eggert <[EMAIL PROTECTED]> wrote:
>
> > Which label will a random USB stick have?
>
> GUID, I presume.
A global unique ID won't work out to make all USB mass storage devices
appear u
On Fri, 12 Aug 2005, Pete Zaitcev wrote:
On Fri, 12 Aug 2005 12:49:28 +0200, Bodo Eggert [EMAIL PROTECTED] wrote:
Which label will a random USB stick have?
GUID, I presume.
A global unique ID won't work out to make all USB mass storage devices
appear under a common mountpoint, especially
On Thu, 11 Aug 2005, Zwane Mwaikambo wrote:
> On Thu, 11 Aug 2005, Steven Rostedt wrote:
> > On Thu, 2005-08-11 at 13:46 -0400, linux-os (Dick Johnson) wrote:
> > int is a call to either an interrupt or exception procedure. 0x80 is
> > setup in Linux to be a trap and not an interrupt vector. So
Horst von Brand <[EMAIL PROTECTED]> wrote:
> DervishD <[EMAIL PROTECTED]> wrote:
>> * Pete Zaitcev <[EMAIL PROTECTED]> dixit:
>> > On Wed, 10 Aug 2005 21:22:43 +0200, DervishD <[EMAIL PROTECTED]> wrote:
>> > > I'm not using hotplug currently so... how can I make the USB
>> > > subsystem to
Horst von Brand [EMAIL PROTECTED] wrote:
DervishD [EMAIL PROTECTED] wrote:
* Pete Zaitcev [EMAIL PROTECTED] dixit:
On Wed, 10 Aug 2005 21:22:43 +0200, DervishD [EMAIL PROTECTED] wrote:
I'm not using hotplug currently so... how can I make the USB
subsystem to assign always the same
On Thu, 11 Aug 2005, Zwane Mwaikambo wrote:
On Thu, 11 Aug 2005, Steven Rostedt wrote:
On Thu, 2005-08-11 at 13:46 -0400, linux-os (Dick Johnson) wrote:
int is a call to either an interrupt or exception procedure. 0x80 is
setup in Linux to be a trap and not an interrupt vector. So it does
On Thu, 11 Aug 2005, Steven Rostedt wrote:
> On Thu, 2005-08-11 at 15:41 +0200, Bodo Eggert wrote:
> > According to my documentation it isn't. A software interrupt is a far call
> > with an extra pushf, and a hardware interrupt is protected against recursion
> > by the PIC
Ukil a <[EMAIL PROTECTED]> wrote:
> Now I had the doubt that if the the syscall
> implementation is very large will the scheduling and
> other interrupts be blocked for the whole time till
> the process returns from the ISR (because in an ISR by
> default the interrupts are disabled unless sti
Ukil a [EMAIL PROTECTED] wrote:
Now I had the doubt that if the the syscall
implementation is very large will the scheduling and
other interrupts be blocked for the whole time till
the process returns from the ISR (because in an ISR by
default the interrupts are disabled unless sti is
On Thu, 11 Aug 2005, Steven Rostedt wrote:
On Thu, 2005-08-11 at 15:41 +0200, Bodo Eggert wrote:
According to my documentation it isn't. A software interrupt is a far call
with an extra pushf, and a hardware interrupt is protected against recursion
by the PIC, not by an interrupt flag
On Tue, 9 Aug 2005, Bodo Eggert wrote:
> On Mon, 8 Aug 2005, Benjamin Herrenschmidt wrote:
> > On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote:
> > > The wrong values are constant across reboots (see my first mail), and I
> > > have a CRT.
> > >
&g
On Tue, 9 Aug 2005, Chris Wright wrote:
> * Bodo Eggert ([EMAIL PROTECTED]) wrote:
> > 1) I wouldn't want an exploited service to gain any privileges, even by
> >chaining userspace exploits (e.g. exec sendmail < exploitstring). For
> >most services, I'd l
On Tue, 9 Aug 2005, Chris Wright wrote:
> * Bodo Eggert ([EMAIL PROTECTED]) wrote:
> > Chris Wright <[EMAIL PROTECTED]> wrote:
> > > * David Madore ([EMAIL PROTECTED]) wrote:
> > >> * Second, a much more extensive change, the patch introduces a third
> >
Chris Wright <[EMAIL PROTECTED]> wrote:
> * David Madore ([EMAIL PROTECTED]) wrote:
>> * Second, a much more extensive change, the patch introduces a third
>> set of capabilities for every process, the "bounding" set. Normally
>
> this is not a good idea. don't add more sets. if you really
On Mon, 8 Aug 2005, Benjamin Herrenschmidt wrote:
> On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote:
> > The wrong values are constant across reboots (see my first mail), and I
> > have a CRT.
> >
> > Can you tell me where the timing values are read?
>
Klasyk <[EMAIL PROTECTED]> wrote:
> my kernel sometimes did a crash, but no panic
> Keyboard hunged up :(
> Network were working and I can log in. Without the keybord - it
> generally worked.
>
> In logs:
> for example:
>
> Aug 6 15:30:02 o kernel: Unable to handle kernel NULL pointer
>
On Tue, 9 Aug 2005, Machida, Hiroyuki wrote:
> Bodo Eggert wrote:
> Please confirm my understanding.
> You sugessted that symlink should not have ATTR_SYS, to prevent
> some over 4KB files created in DOS/WIN to be treated as symlinks?
NACK, files longer than 4KB should not be symlink
On Mon, 8 Aug 2005, Benjamin Herrenschmidt wrote:
On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote:
The wrong values are constant across reboots (see my first mail), and I
have a CRT.
Can you tell me where the timing values are read?
radeon_write_mode() programs the mode
Chris Wright [EMAIL PROTECTED] wrote:
* David Madore ([EMAIL PROTECTED]) wrote:
* Second, a much more extensive change, the patch introduces a third
set of capabilities for every process, the bounding set. Normally
this is not a good idea. don't add more sets. if you really want to
work
On Tue, 9 Aug 2005, Chris Wright wrote:
* Bodo Eggert ([EMAIL PROTECTED]) wrote:
Chris Wright [EMAIL PROTECTED] wrote:
* David Madore ([EMAIL PROTECTED]) wrote:
* Second, a much more extensive change, the patch introduces a third
set of capabilities for every process, the bounding set
On Tue, 9 Aug 2005, Chris Wright wrote:
* Bodo Eggert ([EMAIL PROTECTED]) wrote:
1) I wouldn't want an exploited service to gain any privileges, even by
chaining userspace exploits (e.g. exec sendmail exploitstring). For
most services, I'd like CAP_EXEC being unset (but it doesn't
On Tue, 9 Aug 2005, Bodo Eggert wrote:
On Mon, 8 Aug 2005, Benjamin Herrenschmidt wrote:
On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote:
The wrong values are constant across reboots (see my first mail), and I
have a CRT.
Can you tell me where the timing values are read
On Tue, 9 Aug 2005, Machida, Hiroyuki wrote:
Bodo Eggert wrote:
Please confirm my understanding.
You sugessted that symlink should not have ATTR_SYS, to prevent
some over 4KB files created in DOS/WIN to be treated as symlinks?
NACK, files longer than 4KB should not be symlinks, and maybe
Klasyk [EMAIL PROTECTED] wrote:
my kernel sometimes did a crash, but no panic
Keyboard hunged up :(
Network were working and I can log in. Without the keybord - it
generally worked.
In logs:
for example:
Aug 6 15:30:02 o kernel: Unable to handle kernel NULL pointer
dereference at
Hiroyuki Machida <[EMAIL PROTECTED]> wrote:
> For newly created and/or modified files/dirs, system can utilize
> full posix attributes, because memory resident inode storage can
> hold those. After umount-mount cycle, system may lose some
> attributes to preserve VFAT format.
Inodes may be
Hiroyuki Machida [EMAIL PROTECTED] wrote:
For newly created and/or modified files/dirs, system can utilize
full posix attributes, because memory resident inode storage can
hold those. After umount-mount cycle, system may lose some
attributes to preserve VFAT format.
Inodes may be reclaimed,
On Sun, 7 Aug 2005, Benjamin Herrenschmidt wrote:
> On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote:
> > On Sun, 7 Aug 2005, Kyle Moffett wrote:
> > > On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
> > > > Ah ! Interesting... I don't see why
On Sun, 7 Aug 2005, Kyle Moffett wrote:
> On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
> > Ah ! Interesting... I don't see why PREEMPT would affect radeonfb
> > though ... Can you try something like wrapper radeon_write_mode() with
> > preempt_disable()/preempt_enable() and tell me
On Sun, 7 Aug 2005, Kyle Moffett wrote:
On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
Ah ! Interesting... I don't see why PREEMPT would affect radeonfb
though ... Can you try something like wrapper radeon_write_mode() with
preempt_disable()/preempt_enable() and tell me if it
On Sun, 7 Aug 2005, Benjamin Herrenschmidt wrote:
On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote:
On Sun, 7 Aug 2005, Kyle Moffett wrote:
On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
Ah ! Interesting... I don't see why PREEMPT would affect radeonfb
though ... Can
On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote:
> On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote:
> > My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized.
> > 2.6.12 does not show this behaviour.
>
> I'm out of town at the moment, could you maybe
On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote:
On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote:
My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized.
2.6.12 does not show this behaviour.
I'm out of town at the moment, could you maybe diff radeonfb between
working
My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized.
2.6.12 does not show this behaviour.
dmesg from both systems, trimmed down:
2.6.13-rc5:
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Boot video device is :01:00.0
PCI: Using IRQ router VIA [1106/0686] at
My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized.
2.6.12 does not show this behaviour.
dmesg from both systems, trimmed down:
2.6.13-rc5:
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Boot video device is :01:00.0
PCI: Using IRQ router VIA [1106/0686] at
Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> This small patch will allow no_overlay flag to disable BTTV driver to
> report OVERLAY capabilities. It should fix your troubles by enabling
> no_overlay=1 when inserting bttv module.
>
> This patch is against our CVS tree, but should apply with
On Wed, 3 Aug 2005, Jesper Juhl wrote:
> +What is a patch?
> +To correctly apply a patch you need to know what base it was generated from
> +and what new version the patch will change the source tree into. These
> +should both be present in the patch file metadata.
This is usurally not true for
On Tue, 2 Aug 2005, H. Peter Anvin wrote:
> Michael Krufky wrote:
> > Why not just have the scripts plug values into a database, and have the
> > html/php be formatted like Bodo suggests, and reads content from database?
> > Very simple, less maintenance... Only requires 1 initial redesign, and
On Tue, 2 Aug 2005, H. Peter Anvin wrote:
Michael Krufky wrote:
Why not just have the scripts plug values into a database, and have the
html/php be formatted like Bodo suggests, and reads content from database?
Very simple, less maintenance... Only requires 1 initial redesign, and
On Wed, 3 Aug 2005, Jesper Juhl wrote:
+What is a patch?
+To correctly apply a patch you need to know what base it was generated from
+and what new version the patch will change the source tree into. These
+should both be present in the patch file metadata.
This is usurally not true for
Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
This small patch will allow no_overlay flag to disable BTTV driver to
report OVERLAY capabilities. It should fix your troubles by enabling
no_overlay=1 when inserting bttv module.
This patch is against our CVS tree, but should apply with some
ll download links to a seperate table, where they can be found.
- Add headings above the patches and above the tarballs
- Add some hints
- Create a dead link to a patching-HOWTO
- Add a 'applies to:' column
- fix legend to match changes
Signed-off-by: Bodo Eggert <[EMAIL PROTECTED]>
--- index
the patches and above the tarballs
- Add some hints
- Create a dead link to a patching-HOWTO
- Add a 'applies to:' column
- fix legend to match changes
Signed-off-by: Bodo Eggert [EMAIL PROTECTED]
--- index.ori 2005-08-03 02:26:03.618204515 +0200
+++ index.html 2005-08-03 02:35:57.326133017 +0200
Andrew Burgess <[EMAIL PROTECTED]> wrote:
> This is a busy machine. There is continuous usb soundcard (3 soundcards) and
> usb ethernet activity (news server and alot of downloading) and video is being
> read continuously from the bt878 card.
^
Let me guess: A VIA
Andrew Burgess [EMAIL PROTECTED] wrote:
This is a busy machine. There is continuous usb soundcard (3 soundcards) and
usb ethernet activity (news server and alot of downloading) and video is being
read continuously from the bt878 card.
^
Let me guess: A VIA
On Thu, 21 Jul 2005, randy_dunlap wrote:
> On Sun, 17 Jul 2005 13:29:03 +0200 (CEST) Bodo Eggert wrote:
> > > These patches change some menus into menuconfig options.
> When using xconfig (not menuconfig), the drivers/MTD menu
> needs some help IMO, but it's not clear wher
On Sat, 23 Jul 2005, Adrian Bunk wrote:
> On Tue, Jul 19, 2005 at 10:50:53PM +0200, Bodo Eggert wrote:
> > OTOH, the build system
> > should automatically propagate the dependencies. I asume that should be
> > easy, except for having the time to implement that.
> >..
On Sat, 23 Jul 2005, Adrian Bunk wrote:
On Tue, Jul 19, 2005 at 10:50:53PM +0200, Bodo Eggert wrote:
OTOH, the build system
should automatically propagate the dependencies. I asume that should be
easy, except for having the time to implement that.
...
There are nontrivial problems
On Thu, 21 Jul 2005, randy_dunlap wrote:
On Sun, 17 Jul 2005 13:29:03 +0200 (CEST) Bodo Eggert wrote:
These patches change some menus into menuconfig options.
When using xconfig (not menuconfig), the drivers/MTD menu
needs some help IMO, but it's not clear where/why.
Before the patch
On Thu, 21 Jul 2005, randy_dunlap wrote:
> On Sun, 17 Jul 2005 19:03:09 +0200 (CEST) Bodo Eggert wrote:
> > On Sun, 17 Jul 2005, Bodo Eggert wrote:
> > > On Sun, 17 Jul 2005, Bodo Eggert wrote:
> >
> > > > These patches change some menus into menuconfig options
On Thu, 21 Jul 2005, randy_dunlap wrote:
On Sun, 17 Jul 2005 19:03:09 +0200 (CEST) Bodo Eggert wrote:
On Sun, 17 Jul 2005, Bodo Eggert wrote:
On Sun, 17 Jul 2005, Bodo Eggert wrote:
These patches change some menus into menuconfig options.
Reworked to apply to linux-2.6.13-rc3
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> 3) If a normal line of code is more than 80 characters, one of the
>> following is probably true: you need to break the line up and use temps
>> for clarity, or your function is so big that you're tabbing over too
>> far.
>
> (Find source files,
Jan Engelhardt [EMAIL PROTECTED] wrote:
3) If a normal line of code is more than 80 characters, one of the
following is probably true: you need to break the line up and use temps
for clarity, or your function is so big that you're tabbing over too
far.
(Find source files, expand tab chars
On Tue, 19 Jul 2005, Adrian Bunk wrote:
> On Sun, Jul 17, 2005 at 05:07:48PM +0200, Bodo Eggert wrote:
> > In sound/isa/Kconfig, select ISAPNP and depend on ISAPNP are intermixed,
> > resulting in funny behaviour. (Soundcarts get selectable if other
> > so
Ivan Yosifov <[EMAIL PROTECTED]> wrote:
> -march implies -mtune and also implies thing like -msse2 for the
> instruction set where applicable.
> I think -march=pentium4 is equivalent to -mmmx -msse -msse2
> -mtune=pentium4 ( if I have not fogotten anything ).
> Pentium4 supports things like sse2
Ivan Yosifov [EMAIL PROTECTED] wrote:
-march implies -mtune and also implies thing like -msse2 for the
instruction set where applicable.
I think -march=pentium4 is equivalent to -mmmx -msse -msse2
-mtune=pentium4 ( if I have not fogotten anything ).
Pentium4 supports things like sse2 and mmx
On Tue, 19 Jul 2005, Adrian Bunk wrote:
On Sun, Jul 17, 2005 at 05:07:48PM +0200, Bodo Eggert wrote:
In sound/isa/Kconfig, select ISAPNP and depend on ISAPNP are intermixed,
resulting in funny behaviour. (Soundcarts get selectable if other
soundcards are selected).
This patch
On Sun, 17 Jul 2005, Bodo Eggert wrote:
> On Sun, 17 Jul 2005, Bodo Eggert wrote:
> > These patches change some menus into menuconfig options.
> >
> > Reworked to apply to linux-2.6.13-rc3-git3
>
> Mostly robotic works.
Fixup: unbreak i2c menu
--
Fun things to
On Sun, 17 Jul 2005, Roman Zippel wrote:
> On Sun, 17 Jul 2005, Bodo Eggert wrote:
>
> > These patches change some menus into menuconfig options.
> I like it, but I would prefer to give it first a bit more exposure in -mm,
> as it does change the menu structure and the b
401 - 500 of 739 matches
Mail list logo
