insertions(+), 5 deletions(-)
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
--- a/sound/isa/Kconfig 2005-07-17 08:10:20.0 +0200
+++ b/sound/isa/Kconfig 2005-07-17 16:57:53.0 +0200
@@ -15,7 +15,8 @@ config SND_CS4231_LIB
config SND_AD1816A
tristate "Analog Devi
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
The Fusion driver is basically a scsi driver (isn't it?). Move it
to the other drivers and above the SCSI debugging driver.
arch/ar
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
The oprofile menu
./arch/alpha/oprofile/Kconfig | 10 ++
./arch/arm/oprofile/Kconfig | 10 ++
./arch/i386
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
CPU frequency scaling menu
arch/arm/Kconfig |4
arch/i386/kernel/cpu/cpufreq/Kconfig |4
arch/s
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
The APM menu.
arch/i386/Kconfig | 18 +-
1 files changed, 5 insertions(+), 13 deletions(-)
Signed-Off-By: Bodo Egger
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
The USB menu.
drivers/usb/Kconfig | 18 ++
drivers/usb/atm/Kconfig |7 +--
drivers/usb/class/Kconfig
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.
drivers/acpi/Kconfig| 10 ++
drivers/cdrom/Kconfig |8 ++--
drivers/
These patches change some menus into menuconfig options.
Reworked to apply to linux-2.6.13-rc3-git3
--
Top 100 things you don't want the sysadmin to say:
17. dd if=/dev/null of=/vmunix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Jan Blunck <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > Does it really matter?
> >
>
> Yes! At least for me and my union mounts implementation.
Is there a reason for not using size == link-count (or even static)?
--
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
Jan Blunck [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Does it really matter?
Yes! At least for me and my union mounts implementation.
Is there a reason for not using size == link-count (or even static)?
--
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
These patches change some menus into menuconfig options.
Reworked to apply to linux-2.6.13-rc3-git3
--
Top 100 things you don't want the sysadmin to say:
17. dd if=/dev/null of=/vmunix
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
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.
drivers/acpi/Kconfig| 10 ++
drivers/cdrom/Kconfig |8 ++--
drivers/char/ipmi
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
The USB menu.
drivers/usb/Kconfig | 18 ++
drivers/usb/atm/Kconfig |7 +--
drivers/usb/class/Kconfig | 11
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
The APM menu.
arch/i386/Kconfig | 18 +-
1 files changed, 5 insertions(+), 13 deletions(-)
Signed-Off-By: Bodo Eggert [EMAIL
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
CPU frequency scaling menu
arch/arm/Kconfig |4
arch/i386/kernel/cpu/cpufreq/Kconfig |4
arch/sh/Kconfig
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
The oprofile menu
./arch/alpha/oprofile/Kconfig | 10 ++
./arch/arm/oprofile/Kconfig | 10 ++
./arch/i386/oprofile/Kconfig
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
The Fusion driver is basically a scsi driver (isn't it?). Move it
to the other drivers and above the SCSI debugging driver.
arch/arm/Kconfig
(+), 5 deletions(-)
Signed-Off-By: Bodo Eggert [EMAIL PROTECTED]
--- a/sound/isa/Kconfig 2005-07-17 08:10:20.0 +0200
+++ b/sound/isa/Kconfig 2005-07-17 16:57:53.0 +0200
@@ -15,7 +15,8 @@ config SND_CS4231_LIB
config SND_AD1816A
tristate Analog Devices SoundPort AD1816A
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 behaviour is little
different
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 slip into your budget
Half a million
Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> text with 8-char tabs:
>
> struct s {
> int n; /* comment */
> unsigned int u; /* comment */
> };
>
> Same text viewed with tabs set to 4-char width:
>
> struct s {
> int n; /* comment */
> unsigned int u; /*
Denis Vlasenko [EMAIL PROTECTED] wrote:
text with 8-char tabs:
struct s {
int n; /* comment */
unsigned int u; /* comment */
};
Same text viewed with tabs set to 4-char width:
struct s {
int n; /* comment */
unsigned int u; /* comment */
};
On Sat, 9 Jul 2005, Adrian Bunk wrote:
> On Sat, Jul 09, 2005 at 09:37:48AM +0200, Bodo Eggert wrote:
[menu dependencies "if" vs. "depends on"]
> > It should be, but either it's really applied to the config instead of the
> > prompt (in which can a
Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> Changes to comply with CodingStyle: // comments converted to /* */
> +[ 22 ] = KEY_SUBTITLE,/* CC */
> +[ 13 ] = KEY_TEXT,/* TTX */
> +[ 11 ] = KEY_TV,/* AIR/CBL */
> +
On Sat, 9 Jul 2005, Adrian Bunk wrote:
> On Mon, Jul 04, 2005 at 04:59:18PM +0200, Bodo Eggert wrote:
...
> > Therefore I can't use
> > config SGI_IOC4
> > tristate
> > prompt "SGI IOC4 Base IO support" if PROMPT_FOR_UNUSED_CORES
> >
On Fri, 8 Jul 2005, Mauro Carvalho Chehab wrote:
> It looks to be an old reported trouble with bttv cards.
>
> There is a doc at kernel that treats this subject. It is at:
> Documentation/video4linux/bttv/README.freeze
>
>
> Overlay works by transfering data
On Fri, 8 Jul 2005, Mauro Carvalho Chehab wrote:
It looks to be an old reported trouble with bttv cards.
There is a doc at kernel that treats this subject. It is at:
Documentation/video4linux/bttv/README.freeze
Overlay works by transfering data from BTTV
On Sat, 9 Jul 2005, Adrian Bunk wrote:
On Mon, Jul 04, 2005 at 04:59:18PM +0200, Bodo Eggert wrote:
...
Therefore I can't use
config SGI_IOC4
tristate
prompt SGI IOC4 Base IO support if PROMPT_FOR_UNUSED_CORES
depends on (IA64_GENERIC || IA64_SGI_SN2) MMTIMER
default
Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
Changes to comply with CodingStyle: // comments converted to /* */
+[ 22 ] = KEY_SUBTITLE,/* CC */
+[ 13 ] = KEY_TEXT,/* TTX */
+[ 11 ] = KEY_TV,/* AIR/CBL */
+[ 17
On Sat, 9 Jul 2005, Adrian Bunk wrote:
On Sat, Jul 09, 2005 at 09:37:48AM +0200, Bodo Eggert wrote:
[menu dependencies if vs. depends on]
It should be, but either it's really applied to the config instead of the
prompt (in which can also be added to the depends on list
Clemens Koller <[EMAIL PROTECTED]> wrote:
> Well, sure, it's not a notebook HDD, but maybe it's possible
> to give headpark a more generic way to get the heads parked?
I remember my old MFM HDD, which had a Landing Zone stored in the BIOS to
which the park command would seek. Maybe you could do
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> Now I've upgraded to X.org 6.8.2 and done a first stress-test (copying
> large files from network to local HDD), and I still can post.
It occured again. So it wasn't that easy.
--
Ich danke GMX dafür, die Verwendung meiner Adressen mit
Bodo Eggert [EMAIL PROTECTED] wrote:
Now I've upgraded to X.org 6.8.2 and done a first stress-test (copying
large files from network to local HDD), and I still can post.
It occured again. So it wasn't that easy.
--
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
Clemens Koller [EMAIL PROTECTED] wrote:
Well, sure, it's not a notebook HDD, but maybe it's possible
to give headpark a more generic way to get the heads parked?
I remember my old MFM HDD, which had a Landing Zone stored in the BIOS to
which the park command would seek. Maybe you could do
Jeremy Laine <[EMAIL PROTECTED]> wrote:
> I keep getting OOPS's when using a Bt878 TV card, I am basically unable to
> watch TV for more than about 20-30mn without my system grinding to a halt. If
> I do not make use of the bttv module, the system is perfectly stable. I saw
> the bttv module is
Jeremy Laine [EMAIL PROTECTED] wrote:
I keep getting OOPS's when using a Bt878 TV card, I am basically unable to
watch TV for more than about 20-30mn without my system grinding to a halt. If
I do not make use of the bttv module, the system is perfectly stable. I saw
the bttv module is marked
--- Documentation/kbuild/kconfig-language.txt ---
- input prompt: "prompt" ["if" ]
Every menu entry can have at most one prompt, which is used to display
to the user. Optionally dependencies only for this prompt can be added
with "if".
---
This is misleading, since the "if" will not affect
On Mon, 4 Jul 2005, Bodo Eggert wrote:
> And now to something completely different:
>
> The Fusion MPT controler seems to belong into the SCSI low level driver
> submenu. I may well be wrong here.
patch is for 2.6.13
--- rc1-a/arch/arm/Kconfig 2005-07-04 15:28:02.0 +
On Mon, 4 Jul 2005, Bodo Eggert wrote:
> Part 4: The profiling menu.
^
Obviously I can't count to 5.
And now to something completely different:
The Fusion MPT controler seems to belong into the SCSI low level driver
submenu. I may well be wrong here.
patch is for 2.6.12, 2.6
> Part 1: The easy stuff.
>
> In many config submenus, the first menu option will enable the rest
> of the menu options. For these menus, It's appropriate to use the more
> convenient "menuconfig" keyword.
>
> I hope I got it right, especially the conversions to "if SYMBOL" and
> merging the
On Fri, 1 Jul 2005, Bodo Eggert wrote:
> Part 1b: The easy stuff for 2.6.13-rc1.
This is the same patch without the changes in /net, as requested by Sam
Ravnborg. It does include the first update.
--- rc1-a/drivers/md/Kconfig2005-06-30 11:21:40.0 +0200
+++ rc1-b/drivers/md/Kcon
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> I see your point. But then this is really not a security issue, but
> an "are you sure you want to format C:" style protection for the
> user's own sake. Adding a mount option (checked by the library) for
> this would be fine. E.g. with
Part 4b: The CPU scaling menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient "menuconfig" keyword.
This patch applies to 2.6.12 and 2.6.13-rc1
--- x/drivers/cpufreq/Kconfig 2005-07-04
On Mon, 4 Jul 2005, Sam Ravnborg wrote:
> On Thu, Jun 30, 2005 at 11:06:01PM +0200, Bodo Eggert wrote:
> > Part 1: The easy stuff.
> > In many config submenus, the first menu option will enable the rest
> > of the menu options. For these menus, It's appropriate to use the
Part 1b: The easy stuff.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient "menuconfig" keyword.
These are some missing changes from the first patch(es).
I don't know where they went missing.
Part 2b: The USB menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient "menuconfig" keyword.
Patch for .13-rc1.
This patch includes the missing changes from the previous patch
---
Part 2b: The USB menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient "menuconfig" keyword.
This patch includes the missing changes from the previous patch
--- x/drivers/usb/atm/Kconfig
On Mon, 4 Jul 2005, Russell King wrote:
> On Mon, Jul 04, 2005 at 12:43:56PM +0200, Bodo Eggert wrote:
> > Part 4: The CPU scaling menu.
> >
> > In many config submenus, the first menu option will enable the rest
> > of the menu options. For these menus, It's
Part 4: The profiling menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient "menuconfig" keyword.
This patch is designed for 2.6.12 and .13-rc1
--- a/./arch/sh/oprofile/Kconfig
Part 4: The CPU scaling menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient "menuconfig" keyword.
This patch is designed for 2.6.13-rc1
--- rc1-a/./arch/sh/Kconfig 2005-06-30
On Mon, 4 Jul 2005, Bodo Eggert wrote:
Part 4: The CPU scaling menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient "menuconfig" keyword.
This patch is designed for 2.6.12 ,
On Mon, 4 Jul 2005, Bodo Eggert wrote:
Part 3: The APM menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient "menuconfig" keyword.
This patch is designed for .13-rc1.
--- rc1-a/.
Part 3: The APM menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient "menuconfig" keyword.
This patch is designed for 2.6.12; the patch for .13-rc1 will be posted
as a reply.
---
Part 2: The USB menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient "menuconfig" keyword.
Patch for .13-rc1. Only offset changes compared to .12.
--- rc1-a/./drivers/usb/net/Kconfig
Part 2: The USB menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient "menuconfig" keyword.
This patch is designed for 2.6.12; the patch for .13-rc1 will be posted
as a reply.
---
Part 2: The USB menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient menuconfig keyword.
This patch is designed for 2.6.12; the patch for .13-rc1 will be posted
as a reply.
---
Part 2: The USB menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient menuconfig keyword.
Patch for .13-rc1. Only offset changes compared to .12.
--- rc1-a/./drivers/usb/net/Kconfig
Part 3: The APM menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient menuconfig keyword.
This patch is designed for 2.6.12; the patch for .13-rc1 will be posted
as a reply.
---
On Mon, 4 Jul 2005, Bodo Eggert wrote:
Part 3: The APM menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient menuconfig keyword.
This patch is designed for .13-rc1.
--- rc1-a/./arch/i386
On Mon, 4 Jul 2005, Bodo Eggert wrote:
Part 4: The CPU scaling menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient menuconfig keyword.
This patch is designed for 2.6.12 , the patch for .13
Part 4: The CPU scaling menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient menuconfig keyword.
This patch is designed for 2.6.13-rc1
--- rc1-a/./arch/sh/Kconfig 2005-06-30
Part 4: The profiling menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient menuconfig keyword.
This patch is designed for 2.6.12 and .13-rc1
--- a/./arch/sh/oprofile/Kconfig
On Mon, 4 Jul 2005, Russell King wrote:
On Mon, Jul 04, 2005 at 12:43:56PM +0200, Bodo Eggert wrote:
Part 4: The CPU scaling menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient
Part 2b: The USB menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient menuconfig keyword.
This patch includes the missing changes from the previous patch
--- x/drivers/usb/atm/Kconfig
Part 2b: The USB menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient menuconfig keyword.
Patch for .13-rc1.
This patch includes the missing changes from the previous patch
---
Part 1b: The easy stuff.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient menuconfig keyword.
These are some missing changes from the first patch(es).
I don't know where they went missing.
On Mon, 4 Jul 2005, Sam Ravnborg wrote:
On Thu, Jun 30, 2005 at 11:06:01PM +0200, Bodo Eggert wrote:
Part 1: The easy stuff.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient menuconfig
Part 4b: The CPU scaling menu.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient menuconfig keyword.
This patch applies to 2.6.12 and 2.6.13-rc1
--- x/drivers/cpufreq/Kconfig 2005-07-04
Miklos Szeredi [EMAIL PROTECTED] wrote:
I see your point. But then this is really not a security issue, but
an are you sure you want to format C: style protection for the
user's own sake. Adding a mount option (checked by the library) for
this would be fine. E.g. with mount_nonempty it
On Fri, 1 Jul 2005, Bodo Eggert wrote:
Part 1b: The easy stuff for 2.6.13-rc1.
This is the same patch without the changes in /net, as requested by Sam
Ravnborg. It does include the first update.
--- rc1-a/drivers/md/Kconfig2005-06-30 11:21:40.0 +0200
+++ rc1-b/drivers/md/Kconfig
Part 1: The easy stuff.
In many config submenus, the first menu option will enable the rest
of the menu options. For these menus, It's appropriate to use the more
convenient menuconfig keyword.
I hope I got it right, especially the conversions to if SYMBOL and
merging the depends ons.
On Mon, 4 Jul 2005, Bodo Eggert wrote:
Part 4: The profiling menu.
^
Obviously I can't count to 5.
And now to something completely different:
The Fusion MPT controler seems to belong into the SCSI low level driver
submenu. I may well be wrong here.
patch is for 2.6.12, 2.6.13
On Mon, 4 Jul 2005, Bodo Eggert wrote:
And now to something completely different:
The Fusion MPT controler seems to belong into the SCSI low level driver
submenu. I may well be wrong here.
patch is for 2.6.13
--- rc1-a/arch/arm/Kconfig 2005-07-04 15:28:02.0 +0200
+++ rc1-b
--- Documentation/kbuild/kconfig-language.txt ---
- input prompt: prompt prompt [if expr]
Every menu entry can have at most one prompt, which is used to display
to the user. Optionally dependencies only for this prompt can be added
with if.
---
This is misleading, since the if will not
On Fri, 22 Apr 2005, Fab Tillier wrote:
> > From: Bodo Eggert <[EMAIL PROTECTED]>
> > Sent: Friday, April 22, 2005 6:10 AM
> > You can't even set a time limit, the driver may have allocated all DMA
> > memory to queued transfers, and some media needs to get pl
Andy Isaacson <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 20, 2005 at 10:07:45PM -0500, Timur Tabi wrote:
>> I don't know if VM_REGISTERED is a good idea or not, but it should be
>> absolutely impossible for the kernel to reclaim "registered" (aka pinned)
>> memory, no matter what. For RDMA services
Andy Isaacson [EMAIL PROTECTED] wrote:
On Wed, Apr 20, 2005 at 10:07:45PM -0500, Timur Tabi wrote:
I don't know if VM_REGISTERED is a good idea or not, but it should be
absolutely impossible for the kernel to reclaim registered (aka pinned)
memory, no matter what. For RDMA services (such as
On Fri, 22 Apr 2005, Fab Tillier wrote:
From: Bodo Eggert [EMAIL PROTECTED]
Sent: Friday, April 22, 2005 6:10 AM
You can't even set a time limit, the driver may have allocated all DMA
memory to queued transfers, and some media needs to get plugged in by
the lazy robot. As soon
Ed L Cashin <[EMAIL PROTECTED]> wrote:
> +++ b/Documentation/aoe/aoe.txt 2005-04-20 11:42:20.0 -0400
> + When the aoe driver is a module, use
Is there any reason for this inconsistent behaviour?
> + /sys/module/aoe/parameters/aoe_iflist instead of
Ed L Cashin [EMAIL PROTECTED] wrote:
+++ b/Documentation/aoe/aoe.txt 2005-04-20 11:42:20.0 -0400
+ When the aoe driver is a module, use
Is there any reason for this inconsistent behaviour?
+ /sys/module/aoe/parameters/aoe_iflist instead of
^^^
Mike Waychison <[EMAIL PROTECTED]> wrote:
> Consider the following pseudo example:
>
> main():
> chdir("/");
> fd = open(".", O_RDONLY);
> clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
>
> cloned_func:
> fchdir(fd);
> chdir("..");
>
> if main is run within a chroot where it's "/" is on
Allison <[EMAIL PROTECTED]> wrote:
> I want to find where each module is loaded in memory by traversing the
> module list . Once I have the address and the size of the module, I
> want to read the bytes in memory of the module and hash it to check
> it's integrity.
JFTR: This may work against
Allison [EMAIL PROTECTED] wrote:
I want to find where each module is loaded in memory by traversing the
module list . Once I have the address and the size of the module, I
want to read the bytes in memory of the module and hash it to check
it's integrity.
JFTR: This may work against random
Mike Waychison [EMAIL PROTECTED] wrote:
Consider the following pseudo example:
main():
chdir(/);
fd = open(., O_RDONLY);
clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
cloned_func:
fchdir(fd);
chdir(..);
if main is run within a chroot where it's / is on the same vfsmount as
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
> On 4/19/05, Bodo Eggert <[EMAIL PROTECTED]> wrote:
> > Allowing user mounts with no* should be allways ok (no config needed
> > besides the ulimit), and mounting specified files to defined locations
> > is allready supp
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
> On 4/17/05, Bodo Eggert <[EMAIL PROTECTED]>
> > > I was thinking about this a while back and thought having a user-mount
> > > permissions file might be the right way to address lots of these
> > > issues. Esse
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
On 4/17/05, Bodo Eggert [EMAIL PROTECTED]
I was thinking about this a while back and thought having a user-mount
permissions file might be the right way to address lots of these
issues. Essentially it would contain information about what
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
On 4/19/05, Bodo Eggert [EMAIL PROTECTED] wrote:
Allowing user mounts with no* should be allways ok (no config needed
besides the ulimit), and mounting specified files to defined locations
is allready supported by fstab.
Do folks think
Takashi Ikebe <[EMAIL PROTECTED]> wrote:
> systr_pmem_read() and systr_pmem_write() just calls ptrace
> PTRACE_PEEKTEXT/DATA repeatedly In this case we need to *stop* target
> process whenever patch modules is loading
You'll have to do that anyway, since you'll need to atomically store
Takashi Ikebe [EMAIL PROTECTED] wrote:
systr_pmem_read() and systr_pmem_write() just calls ptrace
PTRACE_PEEKTEXT/DATA repeatedly In this case we need to *stop* target
process whenever patch modules is loading
You'll have to do that anyway, since you'll need to atomically store two
Eric Van Hensbergen <[EMAIL PROTECTED]> wrote:
> On 4/11/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>>
>> 1) Only allow mount over a directory for which the user has write
>> access (and is not sticky)
>>
>> 2) Use nosuid,nodev mount options
[...]
> Do these solve all the security
Eric Van Hensbergen [EMAIL PROTECTED] wrote:
On 4/11/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
1) Only allow mount over a directory for which the user has write
access (and is not sticky)
2) Use nosuid,nodev mount options
[...]
Do these solve all the security concerns with
Ralf Hildebrandt <[EMAIL PROTECTED]> wrote:
> Most UNIX variants disable core dumps in programs that have changed their
> uid or euid during operation. This includes Solaris and Linux.
>
> Well, squid does exactly that. How can I still get a coredump? I really
> need one. Kernel 2.6.11.7
It
Ralf Hildebrandt [EMAIL PROTECTED] wrote:
Most UNIX variants disable core dumps in programs that have changed their
uid or euid during operation. This includes Solaris and Linux.
Well, squid does exactly that. How can I still get a coredump? I really
need one. Kernel 2.6.11.7
It cannot
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
>> Is there a way to check what firmware a drive has
>
> The obvious one: hdparm
Or, since hdparm doesn't work for SCSI devices,
cat /sys/block/sd$n/device/rev
(might depend on t
Richard B. Johnson <[EMAIL PROTECTED]> wrote:
> LD_PRELOAD some custom 'C' runtime library functions, grab open()
> read(), write(), etc.
This will work wonderfully with static binaries.
--
"Bravery is being the only one who knows you're afraid."
-David Hackworth
-
To unsubscribe from this
Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
> Is there a way to check what firmware a drive has
The obvious one: hdparm
--
"Just because you are paranoid, do'nt mean they're not after you."
-- K.Cobain
Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
-
To unsubscribe from this
Tomasz Chmielewski [EMAIL PROTECTED] wrote:
Is there a way to check what firmware a drive has
The obvious one: hdparm
--
Just because you are paranoid, do'nt mean they're not after you.
-- K.Cobain
Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
-
To unsubscribe from this list:
Richard B. Johnson [EMAIL PROTECTED] wrote:
LD_PRELOAD some custom 'C' runtime library functions, grab open()
read(), write(), etc.
This will work wonderfully with static binaries.
--
Bravery is being the only one who knows you're afraid.
-David Hackworth
-
To unsubscribe from this list:
Bodo Eggert [EMAIL PROTECTED] wrote:
Tomasz Chmielewski [EMAIL PROTECTED] wrote:
Is there a way to check what firmware a drive has
The obvious one: hdparm
Ingrid
Or, since hdparm doesn't work for SCSI devices,
cat /sys/block/sd$n/device/rev
(might depend on the vendor)
--
Funny quotes:
21
501 - 600 of 739 matches
Mail list logo
