Re: [PATCH 2/25] NTFS: Allow highmem kmalloc() in ntfs_malloc_nofs() and add _nofail() version.

[Horst von Brand]

Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-09-09 at 15:02 +0300, Pekka J Enberg wrote:
> > On Fri, 9 Sep 2005, Anton Altaparmakov wrote:

> > > > I completely disagree with you given that this is not "inventing
> > > > [...] own memory allocators", it is just a convenient short hand.
> > > > I am sure a lot of people would agree with you though.  It is just
> > > > a matter of personal preference.

> > > I should add that this is not ntfs only, the idea is from another file
> > > system which uses it, too.  Can't remember which one it was, though (xfs
> > > maybe?).

> > Indeed. It is not just a matter of personal preference but also a matter 
> > of subsystems introducing duplicate code like this. Quick grepping shows 
> > UDF doing same thing  and XFS doing slightly differently but I am pretty 
> > sure I've seen it elsewhere too.

> Yes, that is usually a good indication that a generic function should be
> provided.  However having a generic function with complicated and long
> arguments is no use as everyone will want their own shorter one anyway.
> And given the function is static inline it actually makes no difference
> to the generated code size.  Also calling it __vmalloc_fast makes no
> sense as it doesn't always use vmalloc...  Given we have kmalloc and
> vmalloc maybe it should be just malloc?

That it makes no difference to the generated code isn't enough. If somebody
if going over the kernel with a fine comb trying to fix memory allocations
(example as here), she will have to remember half a dozen slightly
different ways of doing the same thing, for no good reason. And probably
miss a bundle in the process. This is bad in itself.

> Obviously if there were a suitable generic function I would use it but I
> and I imagine all the other users would still wrap it with the old name.

I'd hope not.

[Yes, I can understand that each subsystem has its own "culture", and
 trying to force them all into the same mold is friction too.]
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/25] NTFS: Allow highmem kmalloc() in ntfs_malloc_nofs() and add _nofail() version.

[Horst von Brand]

Anton Altaparmakov [EMAIL PROTECTED] wrote:
 On Fri, 2005-09-09 at 15:02 +0300, Pekka J Enberg wrote:
  On Fri, 9 Sep 2005, Anton Altaparmakov wrote:

I completely disagree with you given that this is not inventing
[...] own memory allocators, it is just a convenient short hand.
I am sure a lot of people would agree with you though.  It is just
a matter of personal preference.

   I should add that this is not ntfs only, the idea is from another file
   system which uses it, too.  Can't remember which one it was, though (xfs
   maybe?).

  Indeed. It is not just a matter of personal preference but also a matter 
  of subsystems introducing duplicate code like this. Quick grepping shows 
  UDF doing same thing  and XFS doing slightly differently but I am pretty 
  sure I've seen it elsewhere too.

 Yes, that is usually a good indication that a generic function should be
 provided.  However having a generic function with complicated and long
 arguments is no use as everyone will want their own shorter one anyway.
 And given the function is static inline it actually makes no difference
 to the generated code size.  Also calling it __vmalloc_fast makes no
 sense as it doesn't always use vmalloc...  Given we have kmalloc and
 vmalloc maybe it should be just malloc?

That it makes no difference to the generated code isn't enough. If somebody
if going over the kernel with a fine comb trying to fix memory allocations
(example as here), she will have to remember half a dozen slightly
different ways of doing the same thing, for no good reason. And probably
miss a bundle in the process. This is bad in itself.

 Obviously if there were a suitable generic function I would use it but I
 and I imagine all the other users would still wrap it with the old name.

I'd hope not.

[Yes, I can understand that each subsystem has its own culture, and
 trying to force them all into the same mold is friction too.]
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: i386: kill !4KSTACKS

[Horst von Brand]

Willy Tarreau <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 05, 2005 at 12:47:03AM -0400, Sean wrote:

[...]

> > But the real crux of the argument here is not whether or not people should
> > ever use binary-only drivers, it's whether the open source kernel
> > developers should spend any time worrying about it or not.

> I think we should not worry about it, but we should not deliberately break
> it in a stable series when that does not bring anything.

4Kstacks sure /does/ bring something. Quite a lot, actually. Please stop
pretending that the kernel crowd is out to get innocent users just for fun
and games. There /are/ technical reasons behind the change, the change
/has/ been tested for a long time and remaining bugs have (all but) been
flushed out, and now the time for the final step has come (get rid of the
old ways once and for all).

>  The fact that
> Adrian proposed to completely remove the option is sad.

I for one don't see why.

> It's in the windows
> world that you can't choose. In Linux, you make menuconfig and choose what
> suits your needs.

When it goes away, you can fork your own version of the kernel with the
legacy option, or even figure out how to fix the offending user that needs
it (funny, that was exactly what was supposed to happen in the meantime).

You could even try to brib^Wconvince a kernel developer to do the above for
you, or hire a competent hacker. Or even pool your money with others that
see the same need and put out a call for getting it done.

Perhaps even better, put pressure on the vendors that don't want to give
out specs. Find out why, try to find out if something can be worked out
(specs under NDA, but GPLed driver, perhaps).

Yes, Linux /is/ full of options. 

Just go and try to make some piece of ancient hardware work on some of the
propietary systems. /There/ you get no chance but "Oh, just change your
machine". 
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513

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

Re: RFC: i386: kill !4KSTACKS

[Horst von Brand]

Willy Tarreau [EMAIL PROTECTED] wrote:
 On Mon, Sep 05, 2005 at 12:47:03AM -0400, Sean wrote:

[...]

  But the real crux of the argument here is not whether or not people should
  ever use binary-only drivers, it's whether the open source kernel
  developers should spend any time worrying about it or not.

 I think we should not worry about it, but we should not deliberately break
 it in a stable series when that does not bring anything.

4Kstacks sure /does/ bring something. Quite a lot, actually. Please stop
pretending that the kernel crowd is out to get innocent users just for fun
and games. There /are/ technical reasons behind the change, the change
/has/ been tested for a long time and remaining bugs have (all but) been
flushed out, and now the time for the final step has come (get rid of the
old ways once and for all).

  The fact that
 Adrian proposed to completely remove the option is sad.

I for one don't see why.

 It's in the windows
 world that you can't choose. In Linux, you make menuconfig and choose what
 suits your needs.

When it goes away, you can fork your own version of the kernel with the
legacy option, or even figure out how to fix the offending user that needs
it (funny, that was exactly what was supposed to happen in the meantime).

You could even try to brib^Wconvince a kernel developer to do the above for
you, or hire a competent hacker. Or even pool your money with others that
see the same need and put out a call for getting it done.

Perhaps even better, put pressure on the vendors that don't want to give
out specs. Find out why, try to find out if something can be worked out
(specs under NDA, but GPLed driver, perhaps).

Yes, Linux /is/ full of options. 

Just go and try to make some piece of ancient hardware work on some of the
propietary systems. /There/ you get no chance but Oh, just change your
machine. 
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513

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

Re: RFC: i386: kill !4KSTACKS

[Horst von Brand]

Bas Westerbaan <[EMAIL PROTECTED]> wrote:
> > Yes you are. You're asking for 4KSTACKS config option to maintained
> > and it is not something you get for free. Besides, if it is indeed
> > ripped out of mainline kernel, you can always keep it a separate patch
> > for ndiswrapper.

> Though 4K stacks are used a lot, they probably aren't used on all
> configurations yet. Other situations may arise where 8K stacks may be
> preferred. It is too early to kill 8K stacks imho.

At least Fedora ships 4Kstacks kernel for quite a while now. No, it is not
"everywhere", but close.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: forbid to strace a program

[Horst von Brand]

Andreas Hartmann <[EMAIL PROTECTED]> wrote:
1> Alex Riesen wrote:
> > On 9/3/05, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> >> Hello!
> >> Is it possible to prevent a program to be straced on x86?
> >> What do I have to do, eg., to prevent a perl-program to be straced?

Look at the contortions shc does for this.

> > So that none can see what are you doing? Or because your program is
> > breaking because of this? Probably nothing, but someone would like
> > to know what it is you are doing and exactly how it breaks (and, if
> > you don't mind -
> > why it breaks).

> That's not really the problem. I want to hide a clear text password in
> that program (something like ssh-agent or gpg-agent; the last can be
> straced, too :-() which I need for a database when the program runs.

Anyone who can read the executable can find that out. In the worst case, by
running it in a doctored environment that catches the password.

Place it in a file that noone else can read, that way it is also easier to
change.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver

[Horst von Brand]

Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 9/4/05, Harald Welte <[EMAIL PROTECTED]> wrote:
> > On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
> > > Hi!
> > >
> > > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> > > Smartcard Reader.
> > 
> > Sorry, the patch was missing a "cg-add" of the header file.  Please use
> > the patch below.
> 
> It would be so much nicer if the patch actually was "below" - that is
> "inline in the email as opposed to as an attachment". Having to first
> save an attachment and then cut'n'paste from it is a pain.
> 
> Anyway, a few comments below :

[...]

> + unsigned long ulBytesToRead;
> 
> 
> lowercase prefered also for variables.

Also, "encoding" the type (ul) into the variable name is nonsense.

[...]

> + ulMin = (count < (ulBytesToRead+5))?count:(ulBytesToRead+5);

Again.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: forbid to strace a program

[Horst von Brand]

Andreas Hartmann [EMAIL PROTECTED] wrote:
1 Alex Riesen wrote:
  On 9/3/05, Andreas Hartmann [EMAIL PROTECTED] wrote:
  Hello!
  Is it possible to prevent a program to be straced on x86?
  What do I have to do, eg., to prevent a perl-program to be straced?

Look at the contortions shc does for this.

  So that none can see what are you doing? Or because your program is
  breaking because of this? Probably nothing, but someone would like
  to know what it is you are doing and exactly how it breaks (and, if
  you don't mind -
  why it breaks).

 That's not really the problem. I want to hide a clear text password in
 that program (something like ssh-agent or gpg-agent; the last can be
 straced, too :-() which I need for a database when the program runs.

Anyone who can read the executable can find that out. In the worst case, by
running it in a doctored environment that catches the password.

Place it in a file that noone else can read, that way it is also easier to
change.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver

[Horst von Brand]

Jesper Juhl [EMAIL PROTECTED] wrote:
 On 9/4/05, Harald Welte [EMAIL PROTECTED] wrote:
  On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
   Hi!
  
   Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
   Smartcard Reader.
  
  Sorry, the patch was missing a cg-add of the header file.  Please use
  the patch below.
 
 It would be so much nicer if the patch actually was below - that is
 inline in the email as opposed to as an attachment. Having to first
 save an attachment and then cut'n'paste from it is a pain.
 
 Anyway, a few comments below :

[...]

 + unsigned long ulBytesToRead;
 
 
 lowercase prefered also for variables.

Also, encoding the type (ul) into the variable name is nonsense.

[...]

 + ulMin = (count  (ulBytesToRead+5))?count:(ulBytesToRead+5);

Again.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: i386: kill !4KSTACKS

[Horst von Brand]

Bas Westerbaan [EMAIL PROTECTED] wrote:
  Yes you are. You're asking for 4KSTACKS config option to maintained
  and it is not something you get for free. Besides, if it is indeed
  ripped out of mainline kernel, you can always keep it a separate patch
  for ndiswrapper.

 Though 4K stacks are used a lot, they probably aren't used on all
 configurations yet. Other situations may arise where 8K stacks may be
 preferred. It is too early to kill 8K stacks imho.

At least Fedora ships 4Kstacks kernel for quite a while now. No, it is not
everywhere, but close.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c

[Horst von Brand]

Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On Wednesday 24 August 2005 22:39, Brian Gerst wrote:
> > 
> > Do this instead:
> > char ln[LINE_SIZE], *line;
> > 
> Right, now why didn't I think of that :)
> 
> Jeff: Does the patch below agree with you more?
> 
> 
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
> ---
> 
>  usr/gen_init_cpio.c |   22 ++
>  1 files changed, 14 insertions(+), 8 deletions(-)
>  
>  --- linux-2.6.13-rc6-mm2-orig/usr/gen_init_cpio.c2005-06-17 
> 21:48:29.0 +0200
> +++ linux-2.6.13-rc6-mm2/usr/gen_init_cpio.c  2005-08-24 23:10:36.0 
> +0200
> @@ -438,7 +438,8 @@ struct file_handler file_handler_table[]
>  int main (int argc, char *argv[])
>  {
>   FILE *cpio_list;
> - char line[LINE_SIZE];
> + char ln[LINE_SIZE];
> + char *line;
>   char *args, *type;
>   int ec = 0;
>   int line_nr = 0;
> @@ -455,7 +456,7 @@ int main (int argc, char *argv[])
>   exit(1);
>   }
>  
> - while (fgets(line, LINE_SIZE, cpio_list)) {
> + while (line = ln, fgets(line, LINE_SIZE, cpio_list)) {
>   int type_idx;
>   size_t slen = strlen(line);

The ',' in the while() isn't exactly readable... first order of bussiness
inside:

while (fgets(line, LINE_SIZE, cpio_list)) {
while (fgets(ln, LINE_SIZE, cpio_list)) {
int type_idx;
size_t slen = strlen(ln);

line = ln;

Or just use the fact that fgets(3) returns the buffer if no error:

while(line = fgets(ln, LINE_SIZE, cpio_list)) {

(yes, gcc will complain... wrap in () to shut it up)
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Initramfs and TMPFS!

[Horst von Brand]

[EMAIL PROTECTED] wrote:
>>On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote:
>>I don't know, because tar is probably more widely used and
>>consequently people are more familiar with how to use it.
>>>As I said before, the cpio format is cleaner/easier to parse in the
>>>kernel. Everyone has cpio probably so using tar isn't necessary.
> 
> Cpio is perhaps as available as tar, but it's not as used as tar.
> 
> Unless tar would be inordinately larger than a cpio implementation
> (I can't imagine, but I'm not a coder!) I would prefer it.

There are literaly dozens of "tar" formats around, cpio is much more
standardized (and simpler).
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Initramfs and TMPFS!

[Horst von Brand]

[EMAIL PROTECTED] wrote:
On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote:
I don't know, because tar is probably more widely used and
consequently people are more familiar with how to use it.
As I said before, the cpio format is cleaner/easier to parse in the
kernel. Everyone has cpio probably so using tar isn't necessary.
 
 Cpio is perhaps as available as tar, but it's not as used as tar.
 
 Unless tar would be inordinately larger than a cpio implementation
 (I can't imagine, but I'm not a coder!) I would prefer it.

There are literaly dozens of tar formats around, cpio is much more
standardized (and simpler).
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c

[Horst von Brand]

Jesper Juhl [EMAIL PROTECTED] wrote:
 On Wednesday 24 August 2005 22:39, Brian Gerst wrote:
  
  Do this instead:
  char ln[LINE_SIZE], *line;
  
 Right, now why didn't I think of that :)
 
 Jeff: Does the patch below agree with you more?
 
 
 Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
 ---
 
  usr/gen_init_cpio.c |   22 ++
  1 files changed, 14 insertions(+), 8 deletions(-)
  
  --- linux-2.6.13-rc6-mm2-orig/usr/gen_init_cpio.c2005-06-17 
 21:48:29.0 +0200
 +++ linux-2.6.13-rc6-mm2/usr/gen_init_cpio.c  2005-08-24 23:10:36.0 
 +0200
 @@ -438,7 +438,8 @@ struct file_handler file_handler_table[]
  int main (int argc, char *argv[])
  {
   FILE *cpio_list;
 - char line[LINE_SIZE];
 + char ln[LINE_SIZE];
 + char *line;
   char *args, *type;
   int ec = 0;
   int line_nr = 0;
 @@ -455,7 +456,7 @@ int main (int argc, char *argv[])
   exit(1);
   }
  
 - while (fgets(line, LINE_SIZE, cpio_list)) {
 + while (line = ln, fgets(line, LINE_SIZE, cpio_list)) {
   int type_idx;
   size_t slen = strlen(line);

The ',' in the while() isn't exactly readable... first order of bussiness
inside:

while (fgets(line, LINE_SIZE, cpio_list)) {
while (fgets(ln, LINE_SIZE, cpio_list)) {
int type_idx;
size_t slen = strlen(ln);

line = ln;

Or just use the fact that fgets(3) returns the buffer if no error:

while(line = fgets(ln, LINE_SIZE, cpio_list)) {

(yes, gcc will complain... wrap in () to shut it up)
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c

[Horst von Brand]

Jesper Juhl <[EMAIL PROTECTED]> wrote:
> Convert strtok() use to strsep() in usr/gen_init_cpio.c

This is userland code...

No, I'm not looking it over carfully, just a fast look over.

> I've compile tested this patch and it compiles fine.

You should be able ti test it then.

> I build a 2.6.13-rc6-mm2 kernel with the patch applied without problems, and
> the resulting kernel boots and runs just fine (using it right now).
> But despite this basic testing it would still be nice if someone would 
> double-check that I haven't made some silly mistake that would break some 
> other setup than mine.
> 
> 
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
> ---
> 
>  gen_init_cpio.c |   31 ++-
>  1 files changed, 22 insertions(+), 9 deletions(-)
> 
> --- linux-2.6.13-rc6-mm2-orig/usr/gen_init_cpio.c 2005-06-17 
> 21:48:29.0 +0200
> +++ linux-2.6.13-rc6-mm2/usr/gen_init_cpio.c  2005-08-24 18:58:21.0 
> +0200
> @@ -438,7 +438,7 @@ struct file_handler file_handler_table[]
>  int main (int argc, char *argv[])
>  {
>   FILE *cpio_list;
> - char line[LINE_SIZE];
> + char *line, *ln;

No need for this, there is no particular stack frugality requirement with
user code.

>   char *args, *type;
>   int ec = 0;
>   int line_nr = 0;
> @@ -455,7 +455,14 @@ int main (int argc, char *argv[])
>   exit(1);
>   }
>  
> - while (fgets(line, LINE_SIZE, cpio_list)) {
> + ln = malloc(LINE_SIZE);

Ditto.

[...]

> - if ('\n' == *type) {
> + if (!*type || '\n' == *type) {

Redundant. If *type == '\n', it is certainly != 0.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] exterminate strtok - usr/gen_init_cpio.c

[Horst von Brand]

Jesper Juhl [EMAIL PROTECTED] wrote:
 Convert strtok() use to strsep() in usr/gen_init_cpio.c

This is userland code...

No, I'm not looking it over carfully, just a fast look over.

 I've compile tested this patch and it compiles fine.

You should be able ti test it then.

 I build a 2.6.13-rc6-mm2 kernel with the patch applied without problems, and
 the resulting kernel boots and runs just fine (using it right now).
 But despite this basic testing it would still be nice if someone would 
 double-check that I haven't made some silly mistake that would break some 
 other setup than mine.
 
 
 Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
 ---
 
  gen_init_cpio.c |   31 ++-
  1 files changed, 22 insertions(+), 9 deletions(-)
 
 --- linux-2.6.13-rc6-mm2-orig/usr/gen_init_cpio.c 2005-06-17 
 21:48:29.0 +0200
 +++ linux-2.6.13-rc6-mm2/usr/gen_init_cpio.c  2005-08-24 18:58:21.0 
 +0200
 @@ -438,7 +438,7 @@ struct file_handler file_handler_table[]
  int main (int argc, char *argv[])
  {
   FILE *cpio_list;
 - char line[LINE_SIZE];
 + char *line, *ln;

No need for this, there is no particular stack frugality requirement with
user code.

   char *args, *type;
   int ec = 0;
   int line_nr = 0;
 @@ -455,7 +455,14 @@ int main (int argc, char *argv[])
   exit(1);
   }
  
 - while (fgets(line, LINE_SIZE, cpio_list)) {
 + ln = malloc(LINE_SIZE);

Ditto.

[...]

 - if ('\n' == *type) {
 + if (!*type || '\n' == *type) {

Redundant. If *type == '\n', it is certainly != 0.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/RFT 4/5] CLOCK-Pro page replacement

[Horst von Brand]

Rusty Russell <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-08-19 at 00:10 -0700, Andrew Morton wrote:
> > Rusty Russell <[EMAIL PROTECTED]> wrote:
> > > I believe we just ignored sparc64.  That usually works for solving these
> > > kind of bugs. 8)
> > 
> > heh.  iirc, it was demonstrable on x86 also.
> 
> No.  gcc-2.95 on Sparc64 put uninititialized vars into the bss, ignoring
> the __attribute__((section(".data.percpu"))) directive.  x86 certainly
> doesn't have this, I just tested it w/2.95.
> 
> Really, it's Sparc64 + gcc-2.95.  Send an urgent telegram to the user
> telling them to upgrade.

I recently asked if gcc-2.95 was really still supported, and was told that
it is in common use for its speed...
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/RFT 4/5] CLOCK-Pro page replacement

[Horst von Brand]

Rusty Russell [EMAIL PROTECTED] wrote:
 On Fri, 2005-08-19 at 00:10 -0700, Andrew Morton wrote:
  Rusty Russell [EMAIL PROTECTED] wrote:
   I believe we just ignored sparc64.  That usually works for solving these
   kind of bugs. 8)
  
  heh.  iirc, it was demonstrable on x86 also.
 
 No.  gcc-2.95 on Sparc64 put uninititialized vars into the bss, ignoring
 the __attribute__((section(.data.percpu))) directive.  x86 certainly
 doesn't have this, I just tested it w/2.95.
 
 Really, it's Sparc64 + gcc-2.95.  Send an urgent telegram to the user
 telling them to upgrade.

I recently asked if gcc-2.95 was really still supported, and was told that
it is in common use for its speed...
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Undefined behaviour with get_cpu_vendor

[Horst von Brand]

Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 17, 2005 at 11:54:23AM +0200, Christian Ehrhardt wrote:
> > Your Patch at (URL wrapped)
> > 
> > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git; \
> > a=commit;h=99c6e60afff8a7bc6121aeb847dab27c556cf0c9
> > 
> > introduced an additional Parameter (int early) to get_cpu_vendor.
> > However, the same function is called in arch/i386/kernel/apic.c (via
> > an explicit extern declaration that doesn't have the new early parameter.
> 
> Sigh. All people adding externs like this should be ...
> 
> But it won't change anything - the only difference with
> the flag being 0 is to read less fields, but since the function
> has been called earlier and the data has not changed
> the output is always the same.

I'm not so sure that "argument not explicitly given" will always turn out
zero...  more like "random" memory contents.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Undefined behaviour with get_cpu_vendor

[Horst von Brand]

Andi Kleen [EMAIL PROTECTED] wrote:
 On Wed, Aug 17, 2005 at 11:54:23AM +0200, Christian Ehrhardt wrote:
  Your Patch at (URL wrapped)
  
  http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git; \
  a=commit;h=99c6e60afff8a7bc6121aeb847dab27c556cf0c9
  
  introduced an additional Parameter (int early) to get_cpu_vendor.
  However, the same function is called in arch/i386/kernel/apic.c (via
  an explicit extern declaration that doesn't have the new early parameter.
 
 Sigh. All people adding externs like this should be ...
 
 But it won't change anything - the only difference with
 the flag being 0 is to read less fields, but since the function
 has been called earlier and the data has not changed
 the output is always the same.

I'm not so sure that argument not explicitly given will always turn out
zero...  more like random memory contents.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with usb-storage and /dev/sd?

[Horst von Brand]

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 /dev/sd? entry to my USB Mass
> > > storage devices? [...]
> > You cannot. Just mount by label or something...

> Mounting by label won't work, the problem is the /dev entry,
> which changes every time.

That's why you should mount by label...

> > Better yet, install something like Fedora Core 4, which uses HAL,
> > and forget about it. The fstab-sync takes care of the rest.
> 
> Oh no, thanks, I've already used Fedora and it only reinforced my
> feeling about distros: I prefer my do-it-yourself box ;)

In Fedora rawhide it just works. I can't see how the knot you are tying
yourself into by diy is any better...
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with usb-storage and /dev/sd?

[Horst von Brand]

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 /dev/sd? entry to my USB Mass
   storage devices? [...]
  You cannot. Just mount by label or something...

 Mounting by label won't work, the problem is the /dev entry,
 which changes every time.

That's why you should mount by label...

  Better yet, install something like Fedora Core 4, which uses HAL,
  and forget about it. The fstab-sync takes care of the rest.
 
 Oh no, thanks, I've already used Fedora and it only reinforced my
 feeling about distros: I prefer my do-it-yourself box ;)

In Fedora rawhide it just works. I can't see how the knot you are tying
yourself into by diy is any better...
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Any access control mechanism that allow exceptions?

[Horst von Brand]

Xin Zhao <[EMAIL PROTECTED]> wrote:
> I want to lock down a directory to be read-only, say, /etc, for system
> security.

If root can bypass that somehow, it is useless anyway.

>   Unfortunately, some valid system tools might need to
> create/modified files like "/etc/dhclient-eth0.conf".  To avoid
> disrupting the normal running of those tools, I might have to allow
> certain files to be created under /etc.

Use standard permissions, or make affected files inmutable.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Any access control mechanism that allow exceptions?

[Horst von Brand]

Xin Zhao [EMAIL PROTECTED] wrote:
 I want to lock down a directory to be read-only, say, /etc, for system
 security.

If root can bypass that somehow, it is useless anyway.

   Unfortunately, some valid system tools might need to
 create/modified files like /etc/dhclient-eth0.conf.  To avoid
 disrupting the normal running of those tools, I might have to allow
 certain files to be created under /etc.

Use standard permissions, or make affected files inmutable.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc3 current git

[Horst von Brand]

Horst von Brand <[EMAIL PROTECTED]> wrote:
> In arch/i386/kernel/cpu/mtrr/main.c at line 225 it references
> ipi_handler(), a function that is only declared under CONFIG_SMP (from line
> 139 onwards). As a result, the build fails.

Sorry for the noise, a few minutes later the updated git version works.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.13-rc3 current git

[Horst von Brand]

In arch/i386/kernel/cpu/mtrr/main.c at line 225 it references
ipi_handler(), a function that is only declared under CONFIG_SMP (from line
139 onwards). As a result, the build fails.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513

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

2.6.13-rc3 current git

[Horst von Brand]

In arch/i386/kernel/cpu/mtrr/main.c at line 225 it references
ipi_handler(), a function that is only declared under CONFIG_SMP (from line
139 onwards). As a result, the build fails.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513

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

Re: 2.6.13-rc3 current git

[Horst von Brand]

Horst von Brand [EMAIL PROTECTED] wrote:
 In arch/i386/kernel/cpu/mtrr/main.c at line 225 it references
 ipi_handler(), a function that is only declared under CONFIG_SMP (from line
 139 onwards). As a result, the build fails.

Sorry for the noise, a few minutes later the updated git version works.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] include/linux/bio.h: "extern inline" -> "static inline"

[Horst von Brand]

Adrian Bunk <[EMAIL PROTECTED]> wrote:
> "extern inline" doesn't make much sense.

The gcc info here (4.0.1-4 on Fedora rawhide) says it means that the
function should be inlined, and no local copy should be generated
ever. This way the build will bomb out when something isn't inlined.

It also says you should use:

   static inline void foo(some args) __attribute__((always_inline));

as a prototype in this case for future proofing (gcc inlining is not C99
compatible!), but I don't know if that is supported as far back as 2.95.3
(as per Documentation/Changes the required compiler).

Side question: Is there anybody still seriously using such ancient
compilers? I'd guess almost everybody is using newer versions, so this
would really be not a supported combination anymore.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513



-
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/

[no subject]

[Horst von Brand]

[EMAIL PROTECTED] wrote:

> I am currently using Slackware 10.1 with 2.4.29 kernel and encountered
> following problem:

> I use Sagem Fast 800 ADSL modem of my provider and use my linux station
> as a router (iptables+masquerade). The problem is that after a few hours
> of working my linux crashes with the message:

> "
> 
> serwer login: Unable to handle kernel NULL pointer dereference at virtual
> address 0020
> *pde = 
> 0opss: 0002
> CPU: 0
> EIP: 0010:[] Not tainted
> EFLAGS: 00010087
> eax: c11c56 ebx:c11c56c8 ecx:c11a1604 edx: c3139e34
> esi:  edi: c3139e34 ebp: c11c56dc esp: c3385f50
> ds: 0018 es: 0018 ss: 0018
> Process klogd (pid: 63, stackpage=c3385000)
> Stack: 246  c111c5660 0001 ff80 c4958d51 c11c5660 c11c5660
> c3527ee0 0401 c3385fc4 000a c0109fbd 000a c11c55660 c3385fc4
> c03829a0 000a c3527ee0 c3385fc4 c010a138 000a c3385fc4  c3527ee0
> Call Trace: [] [] [] []
> 
> Code: c7 46 20 98 ff ff ff 8b 43 10 8b 80 d8 00 00 00 8b 40 2c 8b
> <0>Kernel panic: Aiee, killing interrupt handler!
> In interrupt handler - not syncing"

First check if there are updates for your distribution, apply them /all/.

Another thing to consider is memory problems. In my experience, this is
often due to CPU overheating (busted fan), bad power, or perhaps bad RAM
(check out memtest86+ ).

Hope this helps
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
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/

[no subject]

[Horst von Brand]

[EMAIL PROTECTED] wrote:

 I am currently using Slackware 10.1 with 2.4.29 kernel and encountered
 following problem:

 I use Sagem Fast 800 ADSL modem of my provider and use my linux station
 as a router (iptables+masquerade). The problem is that after a few hours
 of working my linux crashes with the message:

 
 
 serwer login: Unable to handle kernel NULL pointer dereference at virtual
 address 0020
 *pde = 
 0opss: 0002
 CPU: 0
 EIP: 0010:[c4958ca3] Not tainted
 EFLAGS: 00010087
 eax: c11c56 ebx:c11c56c8 ecx:c11a1604 edx: c3139e34
 esi:  edi: c3139e34 ebp: c11c56dc esp: c3385f50
 ds: 0018 es: 0018 ss: 0018
 Process klogd (pid: 63, stackpage=c3385000)
 Stack: 246  c111c5660 0001 ff80 c4958d51 c11c5660 c11c5660
 c3527ee0 0401 c3385fc4 000a c0109fbd 000a c11c55660 c3385fc4
 c03829a0 000a c3527ee0 c3385fc4 c010a138 000a c3385fc4  c3527ee0
 Call Trace: [c4958d51] [c0109fbd] [c010a138] [c010c428]
 
 Code: c7 46 20 98 ff ff ff 8b 43 10 8b 80 d8 00 00 00 8b 40 2c 8b
 0Kernel panic: Aiee, killing interrupt handler!
 In interrupt handler - not syncing

First check if there are updates for your distribution, apply them /all/.

Another thing to consider is memory problems. In my experience, this is
often due to CPU overheating (busted fan), bad power, or perhaps bad RAM
(check out memtest86+ http://www.memtest.org).

Hope this helps
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] include/linux/bio.h: extern inline - static inline

[Horst von Brand]

Adrian Bunk [EMAIL PROTECTED] wrote:
 extern inline doesn't make much sense.

The gcc info here (4.0.1-4 on Fedora rawhide) says it means that the
function should be inlined, and no local copy should be generated
ever. This way the build will bomb out when something isn't inlined.

It also says you should use:

   static inline void foo(some args) __attribute__((always_inline));

as a prototype in this case for future proofing (gcc inlining is not C99
compatible!), but I don't know if that is supported as far back as 2.95.3
(as per Documentation/Changes the required compiler).

Side question: Is there anybody still seriously using such ancient
compilers? I'd guess almost everybody is using newer versions, so this
would really be not a supported combination anymore.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513



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

Re: Obsolete files in 2.6 tree

[Horst von Brand]

Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Jiri Slaby napsal(a):
> > Are these files obsolete and could be deleted from tree.
> > Does anybody use them? Could anybody compile them?
> 
> New list should be:

[...]

> sound/oss/skeleton.c

I think skeleton.* files are there as examples, not for real use. Sure,
they should be checked that they are up to date and fixed as required.

OSS is obsolete, so this could probably be axed when/if it finally is deleted.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Obsolete files in 2.6 tree

[Horst von Brand]

Jiri Slaby [EMAIL PROTECTED] wrote:
 Jiri Slaby napsal(a):
  Are these files obsolete and could be deleted from tree.
  Does anybody use them? Could anybody compile them?
 
 New list should be:

[...]

 sound/oss/skeleton.c

I think skeleton.* files are there as examples, not for real use. Sure,
they should be checked that they are up to date and fixed as required.

OSS is obsolete, so this could probably be axed when/if it finally is deleted.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel guide to space

[Horst von Brand]

Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 7/11/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:

> [snip]

> > 3e. sizeof
> > space after the operator
> > sizeof a

> I don't think that's a hard rule, there's plenty of code that does 
> "sizeof(type)"  and not  "sizeof (type)", and whitespace cleanup
> patches I've done that change "sizeof (type)" into "sizeof(type)" have
> generally been accepted.

It is necessary /not/ to put space between "function name" and '(', because
if it is a function-like macro, it does matter. For uniformity, do it for
functions and operations like sizeof too.

> [snip]
> > 
> > 4. Indentation rules for C
> > Use tabs, not spaces, for indentation. Tabs should be 8 characters 
> > wide.

> A tab is a tab is a tab, how it's displayed is up to the editor
> showing the file.

But editing a file with tab==4 and editing it later with tab==8 guarantees
a mess.

[...]

> > 6. One-line statement does not need a {} block, so dont put it into one
> > if (foo)
> > bar;

> Not always so, if `bar' is a macro adding {} may be safer.

Such macros are /very/ dangerous. That's one reason why multi-line macros
must be wrapped in "do { ... } while(0)"

>Also
> sometimes adding {} improves readability, which is important.

Or leaves an old C hand wondering what is going on...

> > 7. Comments
> > Dont use C99 // comments.
> > 
> 
> s/Dont/Don't/
> 
> 
> > 9a. Integer types
> > int is the default integer type.
> > Use unsigned type if you perform bit operations (<<,>>,&,|,~).
> > Use unsigned long if you have to fit a pointer into integer.
> > long long is at least 64 bit wide on all platforms.
> > char is for ASCII characters and strings.
> > Use u8,u16,u32,u64 if you need an integer of a specific size.
> 
> u8,s8,u16,s16,u32,s32,u64,s64

Plus annotations for bitwise and such. See Documentation/sparse.txt
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel guide to space

[Horst von Brand]

Jesper Juhl [EMAIL PROTECTED] wrote:
 On 7/11/05, Michael S. Tsirkin [EMAIL PROTECTED] wrote:

 [snip]

  3e. sizeof
  space after the operator
  sizeof a

 I don't think that's a hard rule, there's plenty of code that does 
 sizeof(type)  and not  sizeof (type), and whitespace cleanup
 patches I've done that change sizeof (type) into sizeof(type) have
 generally been accepted.

It is necessary /not/ to put space between function name and '(', because
if it is a function-like macro, it does matter. For uniformity, do it for
functions and operations like sizeof too.

 [snip]
  
  4. Indentation rules for C
  Use tabs, not spaces, for indentation. Tabs should be 8 characters 
  wide.

 A tab is a tab is a tab, how it's displayed is up to the editor
 showing the file.

But editing a file with tab==4 and editing it later with tab==8 guarantees
a mess.

[...]

  6. One-line statement does not need a {} block, so dont put it into one
  if (foo)
  bar;

 Not always so, if `bar' is a macro adding {} may be safer.

Such macros are /very/ dangerous. That's one reason why multi-line macros
must be wrapped in do { ... } while(0)

Also
 sometimes adding {} improves readability, which is important.

Or leaves an old C hand wondering what is going on...

  7. Comments
  Dont use C99 // comments.
  
 
 s/Dont/Don't/
 
 
  9a. Integer types
  int is the default integer type.
  Use unsigned type if you perform bit operations (,,,|,~).
  Use unsigned long if you have to fit a pointer into integer.
  long long is at least 64 bit wide on all platforms.
  char is for ASCII characters and strings.
  Use u8,u16,u32,u64 if you need an integer of a specific size.
 
 u8,s8,u16,s16,u32,s32,u64,s64

Plus annotations for bitwise and such. See Documentation/sparse.txt
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFD] FAT robustness

[Horst von Brand]

Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> > I'd like to have a discussion about FAT robustness.
> > Please give your thought, comments and related issues.

>   What I would like is to treat completely differently writing to
>  FAT (writing to a removeable drive) which need a complete "mount",
>  and just reading quickly a file (a standard use of removeable devices).

Sounds like a job for mtools(1).
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFD] FAT robustness

[Horst von Brand]

Etienne Lorrain [EMAIL PROTECTED] wrote:
  I'd like to have a discussion about FAT robustness.
  Please give your thought, comments and related issues.

   What I would like is to treat completely differently writing to
  FAT (writing to a removeable drive) which need a complete mount,
  and just reading quickly a file (a standard use of removeable devices).

Sounds like a job for mtools(1).
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.13-rc3 from today: No Toshiba ACPI module load?

[Horst von Brand]

I'm getting:
# modprobe toshiba_acpi
FATAL: Error inserting toshiba_acpi 
(/lib/modules/2.6.13-rc3/kernel/drivers/acpi/toshiba_acpi.ko): No such device

This is definitely a Toshiba M30 notebook with this.

On bootup I see:

ACPI: RSDP (v000 TOSHIB) @ 0x000f7a10
ACPI: RSDT (v001 TOSHIB 750  0x00970814 MASM 0x0611) @ 0x1ff63fd8
ACPI: FADT (v002 TOSHIB 750  0x20030101 MASM 0x6110) @ 0x1ff69d03
ACPI: SSDT (v001 TOSHIB A00070x00970814 MSFT 0x010e) @ 0x1ff69d87
ACPI: DBGP (v001 TOSHIB 750  0x00970814 MASM 0x6110) @ 0x1ff69fa4
ACPI: BOOT (v001 TOSHIB 750  0x00970814 MASM 0x0611) @ 0x1ff69fd8
ACPI: DSDT (v001 TOSHIB A00070x20030806 MSFT 0x010e) @ 0x
ACPI: PM-Timer IO Port: 0x1008

Anything else that might be useful?
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.13-rc3 from today: No Toshiba ACPI module load?

[Horst von Brand]

I'm getting:
# modprobe toshiba_acpi
FATAL: Error inserting toshiba_acpi 
(/lib/modules/2.6.13-rc3/kernel/drivers/acpi/toshiba_acpi.ko): No such device

This is definitely a Toshiba M30 notebook with this.

On bootup I see:

ACPI: RSDP (v000 TOSHIB) @ 0x000f7a10
ACPI: RSDT (v001 TOSHIB 750  0x00970814 MASM 0x0611) @ 0x1ff63fd8
ACPI: FADT (v002 TOSHIB 750  0x20030101 MASM 0x6110) @ 0x1ff69d03
ACPI: SSDT (v001 TOSHIB A00070x00970814 MSFT 0x010e) @ 0x1ff69d87
ACPI: DBGP (v001 TOSHIB 750  0x00970814 MASM 0x6110) @ 0x1ff69fa4
ACPI: BOOT (v001 TOSHIB 750  0x00970814 MASM 0x0611) @ 0x1ff69fd8
ACPI: DSDT (v001 TOSHIB A00070x20030806 MSFT 0x010e) @ 0x
ACPI: PM-Timer IO Port: 0x1008

Anything else that might be useful?
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Filesystem capabilities support

[Horst von Brand]

Nicholas Hans Simmonds <[EMAIL PROTECTED]> wrote:

[...]

> Other than this, what are the general thoughts about this method as
> opposed to just using a well defined byte order?

I'd prefer a defined byte order. That way it won't bite too hard if I
happen to move a filesystem (image) from PC to SPARC or whatever.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: eepro100/e100 broken in 2.6.13-rc3

[Horst von Brand]

Jesse Brandeburg <[EMAIL PROTECTED]> wrote:
> On 7/13/05, Mikhail Kshevetskiy <[EMAIL PROTECTED]> wrote:
> > symptom
> > ===
> > modprobe e100
> > ifconfig eth0  netmask 
> > 
> > result:
> > ===
> > SIOCADDRT: Network is unreachable
> > 
> > There were no such error in 2.6.13-rc2

> odd, both e100 and eepro100 are broken?  This might indicate something
> wierd with the pci layer.  Don't know what might cause the Network is
> unreachable...

It works fine here... latest .git from yesterday.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: eepro100/e100 broken in 2.6.13-rc3

[Horst von Brand]

Jesse Brandeburg [EMAIL PROTECTED] wrote:
 On 7/13/05, Mikhail Kshevetskiy [EMAIL PROTECTED] wrote:
  symptom
  ===
  modprobe e100
  ifconfig eth0 ip netmask netmask
  
  result:
  ===
  SIOCADDRT: Network is unreachable
  
  There were no such error in 2.6.13-rc2

 odd, both e100 and eepro100 are broken?  This might indicate something
 wierd with the pci layer.  Don't know what might cause the Network is
 unreachable...

It works fine here... latest .git from yesterday.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Filesystem capabilities support

[Horst von Brand]

Nicholas Hans Simmonds [EMAIL PROTECTED] wrote:

[...]

 Other than this, what are the general thoughts about this method as
 opposed to just using a well defined byte order?

I'd prefer a defined byte order. That way it won't bite too hard if I
happen to move a filesystem (image) from PC to SPARC or whatever.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [11/11] x86_64: TASK_SIZE fixes for compatibility mode processes

[Horst von Brand]

Greg KH <[EMAIL PROTECTED]> wrote:
> -stable review patch.  If anyone has any objections, please let us know.
> Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
> Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
> Cc: Andi Kleen <[EMAIL PROTECTED]>

Huh? Cc: in here?

> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> ---
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Filesystem capabilities support

[Horst von Brand]

Nicholas Hans Simmonds <[EMAIL PROTECTED]> wrote:
> Sorry, my earlier reply seems to have gotten lost somewhere. I've been
> pondering this issue for some time and am still not sure what's the best
> answer. I've attached a small patch which handles this by detecting byte
> swapping of the version code. I'm not convinced it's necessary but
> shouldn't hurt.
> 
> diff --git a/security/commoncap.c b/security/commoncap.c
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -153,6 +153,15 @@ int cap_bprm_set_security (struct linux_
>   down(_dentry->d_inode->i_sem);
>   ret = bprm_getxattr(bprm_dentry,XATTR_CAP_SET,,sizeof(caps));
>   if(ret == sizeof(caps)) {
> + if(caps.version = swab32(_LINUX_CAPABILITY_VERSION)) {
^
|
+-- Surely wrong?!

> + swab32s();
> + swab32s();
> + swab32s(_effective);
> + swab32s();
> + swab32s(_permitted);
> + swab32s();
> + swab32s(_inheritable);
> + }
>   if(caps.version == _LINUX_CAPABILITY_VERSION) {
>   cap_t(bprm->cap_effective) &= caps.mask_effective;
>   cap_t(bprm->cap_effective) |= caps.effective;
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Filesystem capabilities support

[Horst von Brand]

Nicholas Hans Simmonds [EMAIL PROTECTED] wrote:
 Sorry, my earlier reply seems to have gotten lost somewhere. I've been
 pondering this issue for some time and am still not sure what's the best
 answer. I've attached a small patch which handles this by detecting byte
 swapping of the version code. I'm not convinced it's necessary but
 shouldn't hurt.
 
 diff --git a/security/commoncap.c b/security/commoncap.c
 --- a/security/commoncap.c
 +++ b/security/commoncap.c
 @@ -153,6 +153,15 @@ int cap_bprm_set_security (struct linux_
   down(bprm_dentry-d_inode-i_sem);
   ret = bprm_getxattr(bprm_dentry,XATTR_CAP_SET,caps,sizeof(caps));
   if(ret == sizeof(caps)) {
 + if(caps.version = swab32(_LINUX_CAPABILITY_VERSION)) {
^
|
+-- Surely wrong?!

 + swab32s(caps.version);
 + swab32s(caps.effective);
 + swab32s(caps.mask_effective);
 + swab32s(caps.permitted);
 + swab32s(caps.mask_permitted);
 + swab32s(caps.inheritable);
 + swab32s(caps.mask_inheritable);
 + }
   if(caps.version == _LINUX_CAPABILITY_VERSION) {
   cap_t(bprm-cap_effective) = caps.mask_effective;
   cap_t(bprm-cap_effective) |= caps.effective;
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [11/11] x86_64: TASK_SIZE fixes for compatibility mode processes

[Horst von Brand]

Greg KH [EMAIL PROTECTED] wrote:
 -stable review patch.  If anyone has any objections, please let us know.
 Signed-off-by: Zou Nan hai [EMAIL PROTECTED]
 Signed-off-by: Suresh Siddha [EMAIL PROTECTED]
 Cc: Andi Kleen [EMAIL PROTECTED]

Huh? Cc: in here?

 Signed-off-by: Andrew Morton [EMAIL PROTECTED]
 Signed-off-by: Chris Wright [EMAIL PROTECTED]
 Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
 ---
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

David Masover <[EMAIL PROTECTED]> wrote:
> Hans Reiser wrote:
> > Horst von Brand wrote:
> >>Hans Reiser <[EMAIL PROTECTED]> wrote:
> >>>Stefan Smietanowski wrote:

[...]

> > Better to spend one's mind looking for bugs instead of this issue.
> 
> .if bugs were seen as such a big deal.

> I think it's far easier to get into the kernel with something
> ludicrously buggy than something which actually changes fundamental
> behavior.


Wonder why

[Fixing bugs in the $FOO driver or the $BAR filesystem is /easy/, fixing
 bugs in "fundamental behaviour changes" is /extremely hard/.]

>That is, you can put in an FS which actually corrupts data
> (such as the old NTFS write support), so long as it doesn't break POSIX,
> or cause other weird restrictions like "No files named 'metas'"

Because that kind of problems are isolated. If you introduce a change that
affects /all/ filesystems, and that change later on has unfixable bugs, or
fundamental design issues, it is /a lot/ of work.

> Now, if we can decide that we don't care about being in the vanilla
> kernel, then we can just call it ".metas" or "lost+found" or whatever
> and get to work on bug fixes and other much-needed features such as a
> repacker.

Great!
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fdisk: What do plus signs after "Blocks" mean?

[Horst von Brand]

DervishD <[EMAIL PROTECTED]> wrote:

[...]

> It's a good idea to have a copy of the partition table around, if
> it is not simple (the one you had is NOT simple).

Be careful. What you'll get out of backing up the partition table is /only/
the primary partitions, the others are handled by a weird russian doll of
partitions-inside-partitions. AFAIR, the details were in the LILO docu.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

David Masover [EMAIL PROTECTED] wrote:
 Hans Reiser wrote:
  Horst von Brand wrote:
 Hans Reiser [EMAIL PROTECTED] wrote:
 Stefan Smietanowski wrote:

[...]

  Better to spend one's mind looking for bugs instead of this issue.
 
 .if bugs were seen as such a big deal.

 I think it's far easier to get into the kernel with something
 ludicrously buggy than something which actually changes fundamental
 behavior.


Wonder why

[Fixing bugs in the $FOO driver or the $BAR filesystem is /easy/, fixing
 bugs in fundamental behaviour changes is /extremely hard/.]

That is, you can put in an FS which actually corrupts data
 (such as the old NTFS write support), so long as it doesn't break POSIX,
 or cause other weird restrictions like No files named 'metas'

Because that kind of problems are isolated. If you introduce a change that
affects /all/ filesystems, and that change later on has unfixable bugs, or
fundamental design issues, it is /a lot/ of work.

 Now, if we can decide that we don't care about being in the vanilla
 kernel, then we can just call it .metas or lost+found or whatever
 and get to work on bug fixes and other much-needed features such as a
 repacker.

Great!
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fdisk: What do plus signs after Blocks mean?

[Horst von Brand]

DervishD [EMAIL PROTECTED] wrote:

[...]

 It's a good idea to have a copy of the partition table around, if
 it is not simple (the one you had is NOT simple).

Be careful. What you'll get out of backing up the partition table is /only/
the primary partitions, the others are handled by a weird russian doll of
partitions-inside-partitions. AFAIR, the details were in the LILO docu.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

David Masover <[EMAIL PROTECTED]> wrote:

[...]

> Both camps seem to want to allow easy access to the metadata of a
> file, whether we're given that file as an inode or as a pathname.
> That's why I suggested /meta/vfs and /meta/inode -- sometimes I want
> to look up a file by name, and sometimes by inode, but either way, I
> should be able to get its metadata.

You should /never/ give access just by inode, as that makes it very easy to
bypass security given by directory permissions.

> > I mean, editing something is easy and you don't have to "know" how
> > to navigate /meta

> But then you have to "know" how to navigate .meta, and more
> importantly, how to find .meta

And what the heck the format of the metadata is today/for this particular
file.

[...]

> Either way, the major challenge to this method is not so much whether
> it'd work, but how to choose a suitable delimiter?  The delimiter must
> be standard if we're going to have apps develop for it, and it must
> not be used in the name of any existing file or directory.

The only characters that aren't used in filenames today are '/' and '\0'.

> I had a long essay here on how '.meta' breaks every recursive
> operation on directories (rm -rf, tar, mkisofs), but I deleted it when
> I remembered that I played around with the alpha/beta reiser4 which
> had a 'metas' dir that did the same thing, but was hidden from the
> normal directory listing.  'cd metas' worked, 'ls metas' worked, but
> 'ls' showed no directory called 'metas'.

And if I try to create a file or directory called metas?

> I don't *think* there are any apps that will break if you tell them to
> open a path that doesn't exist in a directory listing.  That is,
> typing 'vim /home/metas/acl' should always let me edit the acl on
> /home, and vim should never complain about how /home/metas doesn't
> show up in /home.  A program would have to be pretty retarded to fail
> on something like that.

Think a GUI that reads the directory to find out what is available and
present them as icons for mousing around. Then there is no way to futz
around with your metadata.

Think filename completion, bash style. No, not just bash uses this.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

Hans Reiser <[EMAIL PROTECTED]> wrote:
> Stefan Smietanowski wrote:
> > I think "..." and ".meta" both serve as a logical delimiter. However
> > some programs implement their own "..." which would make it clash with
> > them. Naturally if some program created a directory called .meta we're
> > equally screwed.

> I chose '' (four dots) because it clashes with less, not three dots.

Is this some kind of "My dots are more than yours" contest?!

/None/ of them is safe. ".meta", "...", "", ".this.has.five.dots." are
all perfectly legal file (or directory) names, POSIXly. If any one of them
won't do, none will.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel header policy

[Horst von Brand]

Marc Aurele La France <[EMAIL PROTECTED]> wrote:
> It has been more than a week now...

> -- Forwarded message --
> Date: Sun, 3 Jul 2005 11:12:03 -0600 (MDT)
> From: Marc Aurele La France <[EMAIL PROTECTED]>
> To: Linus Torvalds
> Subject: Kernel header policy

[]

> I am contacting you to express my concern over a growing trend in kernel
> development.  I am specifically referring to changes being made to kernel
> headers that break compatibility at the userland level, where __KERNEL__
> isn't #define'd.

The policy with respect to kernel headers is /very/ simple:

  T H E Y   A R E   N E V E R   U S E D   F R O M   U S E R L A N D.

This general policy makes all your points (trivially) moot.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 vs politics: linux misses out again

[Horst von Brand]

Erik Hensema <[EMAIL PROTECTED]> wrote:
> Horst von Brand ([EMAIL PROTECTED]):
> [on reiserfs4]
> >> >>   and _can_ do things
> >> >> no other FS can

> > Mostly useless things...

> Depends on your point of view. If you define things to be useful
> only when POSIX requires them, then yes, reiser4 contains a lot
> of useless stuff.

That isn't my definition.

> However, it's the 'beyond POSIX'-stuff what makes reiser4
> interesting.

I haven't seen a shred of evidence of that up to here. Just redoing
in-kernel (for completely inscrutable reasons) stuff that has been
confortably done in userland for many years isn't "Interesting", quite the
contrary.

> Multistream files have been useful on other OSses for years.

I only have seen other OSes moving away from such stuff...

>  They
> might be useful on Linux too (Samba will surely like them).

OK, if you think Windows is a good idea all around...

> The plugin architecture is very interesting.

Again: It isn't "plugins", it's "kernel configuration options redefining
the filesystem layout". And that is extremely toxic: If the claims are to
be believed, somebody using ReiserFS 4 could end up using filesystems as
widely different as ext3 and ufs today. Both called the same. Or everybody
will end up using the exact same set of "plugins", so they make no sense as
configuration options. Sure, it is nice to have different versions of the
same filesystem (in a way, ext3 is a version of ext2; in ext3 there are
some options that where introduced later, and some of which aren't
backwards-compatible), but this is not something I would want each
individual user screw around with willy-nilly. So the whole "plugin" idea
is very questionable to me.

>  Sometimes you don't
> need files to be in the POSIX namespace.

The POSIX namespace /is/ the namespace for files.

>  Why would you want to
> store a mysql database in files?

Because it is the abstraction of permanent storage that the OS gives me. Or
I could write them directly on a raw block device for performance (by
cutting out a middleman).

>  Why not skip the overhead of the
> VFS and POSIX rules and just store them in a more efficient way?

Exactly. Cut out the filesystem.

> Maybe you can create a swapfile plugin.

The kernel manages swapping on files and devices just fine, thank you.

> No need for a swapfile to
> be in the POSIX namespace either.

And how do you handle it if it has no filename?!

> It's just a fun thing to experiment with.

Noone here is stopping you from experimenting.

>   It's not always
> nescesary to let the demand create the means. Give programmers
> some powerful tools and wait and see what wonderful things start
> to evolve.

The sad truth is that if you give a random collection of people powerful
tools they misuse them more often than not, creating a huge mess in the
process. That is why it is so hard to design good tools.

> And yes, maybe in ten years time POSIX is just a subsystem in
> Linux. Maybe commerciale Unix vendors will start following Linux
> as 'the' standard instead of the other way around. Seems fun to
> me :-)

To me too. But forcing Linux today to be as non-POSIX as possible, just so
it will be prepared for 10 years in the future makes no sense, because you
break it /now/.

> I think this debate will mostly boil down to 'do we want to
> experiment with beyond-POSIX filesystems in linux?'.

You (and some others) clearly want to. More power to the bunch that comes
up with clean semantics that can be implemented efficiently and are useful
in real life (as opposed to "it would be oh-so-nice to also have $FEATURE
for my pet $NICHE_CASE, feature for which I just can't be bothered
considering ramifications at all"). Before going off look up "featuritis"
(and consider how it all but killed off a lot of OSes, even many Unix
variants, and uncountable other things too).
 
> Clearly we don't _need_ it now. There simply are no users. But
> will users come when reiser4 is merged? Nobody knows.

Probably a tiny minority. Something like the following ReiserFS 3 has
today.

> IMHO reiser4 should be merged and be marked as experimental.

IMHO ReiserFS 4 should not be merged into Linus' kernel. So what? It is not
my call (nor yours).

>  It
> should probably _always_ be marked as experimental, because we
> _know_ we're going to need some other -- more generic -- API when
> we decide we like the features of re

Re: share/private/slave a subtree - define vs enum

[Horst von Brand]

Roman Zippel <[EMAIL PROTECTED]> wrote:
> On Sun, 10 Jul 2005, Pekka Enberg wrote:

[...]

> > Would you please be so kind to define your criteria for things that
> > "need fixing" so we could see if can reach some sort of an agreement on
> > this. My list is roughly as follows:
> > 
> >   - Erroneous use of kernel API
> >   - Bad coding style
> >   - Layering violations
> >   - Duplicate code
> >   - Hard to read code

> I don't generally disagree with that, I just think that defines are not 
> part of that list.

Covered in "bad coding style" and "hard to read code", at least.

> Look, it's great that you do reviews, but please keep in mind it's the 
> author who has to work with code and he has to be primarily happy with, 
> so you don't have to point out every minor issue.

Wrong. The author has to work with the code, but there are much more people
that have to read it now and fix it in the future. It doesn't make sense
having everybody using their own indentation style, variable naming scheme,
and ways of defining constants. For better or worse, #define /is/ the
standard idiom (in kernel and elsewhere) to define constants in C. See also
, particularly
comandment 8. And consider also the /spirit/ of Documentation/CodingStyle.

> Although it also differs between core and driver code, we don't have to be 
> that strict with driver code as longs as it "looks" ok and is otherwise 
> correct. The requirements for core kernel code are higher, but even here 
> defines are a well accepted language construct.

I'd rather ask for the higher requirements of authors of new code... not
demand, just ask.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: share/private/slave a subtree - define vs enum

[Horst von Brand]

Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 10, 2005 at 09:21:42PM +0300, Pekka Enberg wrote:
> > Hmm. So we disagree on that issue as well. I think the point of review
> > is to improve code and help others conform with the existing coding
> > style which is why I find it strange that you're suggesting me to limit
> > my comments to a subset you agree with.
> > 
> > Would you please be so kind to define your criteria for things that
> > "need fixing" so we could see if can reach some sort of an agreement on
> > this. My list is roughly as follows:
> > 
> >   - Erroneous use of kernel API
> >   - Bad coding style
> >   - Layering violations
> >   - Duplicate code
> >   - Hard to read code

> The reason people post their patches for review is to get good feedback
> on them. The problems you list above are mostly nitpicks. They must be
> fixed before inclusion of the patch, but only make sense to start fixing
> once the patch does a reasonable change.

If the coding style is an obstacle to understanding, it has to be fixed if
there is going to be any kind of review. Besides, nitpicks being simple to
address, they could as well be fixed while at it. Perhaps that way the
author learns to do it right, and less nitpicks are left in later additions
and fixes.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 vs politics: linux misses out again

[Horst von Brand]

Erik Hensema [EMAIL PROTECTED] wrote:
 Horst von Brand ([EMAIL PROTECTED]):
 [on reiserfs4]
 and _can_ do things
   no other FS can

  Mostly useless things...

 Depends on your point of view. If you define things to be useful
 only when POSIX requires them, then yes, reiser4 contains a lot
 of useless stuff.

That isn't my definition.

 However, it's the 'beyond POSIX'-stuff what makes reiser4
 interesting.

I haven't seen a shred of evidence of that up to here. Just redoing
in-kernel (for completely inscrutable reasons) stuff that has been
confortably done in userland for many years isn't Interesting, quite the
contrary.

 Multistream files have been useful on other OSses for years.

I only have seen other OSes moving away from such stuff...

  They
 might be useful on Linux too (Samba will surely like them).

OK, if you think Windows is a good idea all around...

 The plugin architecture is very interesting.

Again: It isn't plugins, it's kernel configuration options redefining
the filesystem layout. And that is extremely toxic: If the claims are to
be believed, somebody using ReiserFS 4 could end up using filesystems as
widely different as ext3 and ufs today. Both called the same. Or everybody
will end up using the exact same set of plugins, so they make no sense as
configuration options. Sure, it is nice to have different versions of the
same filesystem (in a way, ext3 is a version of ext2; in ext3 there are
some options that where introduced later, and some of which aren't
backwards-compatible), but this is not something I would want each
individual user screw around with willy-nilly. So the whole plugin idea
is very questionable to me.

  Sometimes you don't
 need files to be in the POSIX namespace.

The POSIX namespace /is/ the namespace for files.

  Why would you want to
 store a mysql database in files?

Because it is the abstraction of permanent storage that the OS gives me. Or
I could write them directly on a raw block device for performance (by
cutting out a middleman).

  Why not skip the overhead of the
 VFS and POSIX rules and just store them in a more efficient way?

Exactly. Cut out the filesystem.

 Maybe you can create a swapfile plugin.

The kernel manages swapping on files and devices just fine, thank you.

 No need for a swapfile to
 be in the POSIX namespace either.

And how do you handle it if it has no filename?!

 It's just a fun thing to experiment with.

Noone here is stopping you from experimenting.

   It's not always
 nescesary to let the demand create the means. Give programmers
 some powerful tools and wait and see what wonderful things start
 to evolve.

The sad truth is that if you give a random collection of people powerful
tools they misuse them more often than not, creating a huge mess in the
process. That is why it is so hard to design good tools.

 And yes, maybe in ten years time POSIX is just a subsystem in
 Linux. Maybe commerciale Unix vendors will start following Linux
 as 'the' standard instead of the other way around. Seems fun to
 me :-)

To me too. But forcing Linux today to be as non-POSIX as possible, just so
it will be prepared for 10 years in the future makes no sense, because you
break it /now/.

 I think this debate will mostly boil down to 'do we want to
 experiment with beyond-POSIX filesystems in linux?'.

You (and some others) clearly want to. More power to the bunch that comes
up with clean semantics that can be implemented efficiently and are useful
in real life (as opposed to it would be oh-so-nice to also have $FEATURE
for my pet $NICHE_CASE, feature for which I just can't be bothered
considering ramifications at all). Before going off look up featuritis
(and consider how it all but killed off a lot of OSes, even many Unix
variants, and uncountable other things too).
 
 Clearly we don't _need_ it now. There simply are no users. But
 will users come when reiser4 is merged? Nobody knows.

Probably a tiny minority. Something like the following ReiserFS 3 has
today.

 IMHO reiser4 should be merged and be marked as experimental.

IMHO ReiserFS 4 should not be merged into Linus' kernel. So what? It is not
my call (nor yours).

  It
 should probably _always_ be marked as experimental, because we
 _know_ we're going to need some other -- more generic -- API when
 we decide we like the features of reiser4. The reiser4 APIs
 should probably be implemented as generic VFS APIs. But since we
 don't know yet what features we're going to use, let reiser4 be
 self contained. Maybe reiser5 or reiser6 will follow standard
 VFS-beyond-POSIX rules, with ext4 and JFS2 also implementing them

Re: share/private/slave a subtree - define vs enum

[Horst von Brand]

Vojtech Pavlik [EMAIL PROTECTED] wrote:
 On Sun, Jul 10, 2005 at 09:21:42PM +0300, Pekka Enberg wrote:
  Hmm. So we disagree on that issue as well. I think the point of review
  is to improve code and help others conform with the existing coding
  style which is why I find it strange that you're suggesting me to limit
  my comments to a subset you agree with.
  
  Would you please be so kind to define your criteria for things that
  need fixing so we could see if can reach some sort of an agreement on
  this. My list is roughly as follows:
  
- Erroneous use of kernel API
- Bad coding style
- Layering violations
- Duplicate code
- Hard to read code

 The reason people post their patches for review is to get good feedback
 on them. The problems you list above are mostly nitpicks. They must be
 fixed before inclusion of the patch, but only make sense to start fixing
 once the patch does a reasonable change.

If the coding style is an obstacle to understanding, it has to be fixed if
there is going to be any kind of review. Besides, nitpicks being simple to
address, they could as well be fixed while at it. Perhaps that way the
author learns to do it right, and less nitpicks are left in later additions
and fixes.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: share/private/slave a subtree - define vs enum

[Horst von Brand]

Roman Zippel [EMAIL PROTECTED] wrote:
 On Sun, 10 Jul 2005, Pekka Enberg wrote:

[...]

  Would you please be so kind to define your criteria for things that
  need fixing so we could see if can reach some sort of an agreement on
  this. My list is roughly as follows:
  
- Erroneous use of kernel API
- Bad coding style
- Layering violations
- Duplicate code
- Hard to read code

 I don't generally disagree with that, I just think that defines are not 
 part of that list.

Covered in bad coding style and hard to read code, at least.

 Look, it's great that you do reviews, but please keep in mind it's the 
 author who has to work with code and he has to be primarily happy with, 
 so you don't have to point out every minor issue.

Wrong. The author has to work with the code, but there are much more people
that have to read it now and fix it in the future. It doesn't make sense
having everybody using their own indentation style, variable naming scheme,
and ways of defining constants. For better or worse, #define /is/ the
standard idiom (in kernel and elsewhere) to define constants in C. See also
http://www.lysator.liu.se/c/ten-commandments.html, particularly
comandment 8. And consider also the /spirit/ of Documentation/CodingStyle.

 Although it also differs between core and driver code, we don't have to be 
 that strict with driver code as longs as it looks ok and is otherwise 
 correct. The requirements for core kernel code are higher, but even here 
 defines are a well accepted language construct.

I'd rather ask for the higher requirements of authors of new code... not
demand, just ask.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel header policy

[Horst von Brand]

Marc Aurele La France [EMAIL PROTECTED] wrote:
 It has been more than a week now...

 -- Forwarded message --
 Date: Sun, 3 Jul 2005 11:12:03 -0600 (MDT)
 From: Marc Aurele La France [EMAIL PROTECTED]
 To: Linus Torvalds
 Subject: Kernel header policy

[]

 I am contacting you to express my concern over a growing trend in kernel
 development.  I am specifically referring to changes being made to kernel
 headers that break compatibility at the userland level, where __KERNEL__
 isn't #define'd.

The policy with respect to kernel headers is /very/ simple:

  T H E Y   A R E   N E V E R   U S E D   F R O M   U S E R L A N D.

This general policy makes all your points (trivially) moot.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

Hans Reiser [EMAIL PROTECTED] wrote:
 Stefan Smietanowski wrote:
  I think ... and .meta both serve as a logical delimiter. However
  some programs implement their own ... which would make it clash with
  them. Naturally if some program created a directory called .meta we're
  equally screwed.

 I chose '' (four dots) because it clashes with less, not three dots.

Is this some kind of My dots are more than yours contest?!

/None/ of them is safe. .meta, ..., , .this.has.five.dots. are
all perfectly legal file (or directory) names, POSIXly. If any one of them
won't do, none will.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

David Masover [EMAIL PROTECTED] wrote:

[...]

 Both camps seem to want to allow easy access to the metadata of a
 file, whether we're given that file as an inode or as a pathname.
 That's why I suggested /meta/vfs and /meta/inode -- sometimes I want
 to look up a file by name, and sometimes by inode, but either way, I
 should be able to get its metadata.

You should /never/ give access just by inode, as that makes it very easy to
bypass security given by directory permissions.

  I mean, editing something is easy and you don't have to know how
  to navigate /meta

 But then you have to know how to navigate .meta, and more
 importantly, how to find .meta

And what the heck the format of the metadata is today/for this particular
file.

[...]

 Either way, the major challenge to this method is not so much whether
 it'd work, but how to choose a suitable delimiter?  The delimiter must
 be standard if we're going to have apps develop for it, and it must
 not be used in the name of any existing file or directory.

The only characters that aren't used in filenames today are '/' and '\0'.

 I had a long essay here on how '.meta' breaks every recursive
 operation on directories (rm -rf, tar, mkisofs), but I deleted it when
 I remembered that I played around with the alpha/beta reiser4 which
 had a 'metas' dir that did the same thing, but was hidden from the
 normal directory listing.  'cd metas' worked, 'ls metas' worked, but
 'ls' showed no directory called 'metas'.

And if I try to create a file or directory called metas?

 I don't *think* there are any apps that will break if you tell them to
 open a path that doesn't exist in a directory listing.  That is,
 typing 'vim /home/metas/acl' should always let me edit the acl on
 /home, and vim should never complain about how /home/metas doesn't
 show up in /home.  A program would have to be pretty retarded to fail
 on something like that.

Think a GUI that reads the directory to find out what is available and
present them as icons for mousing around. Then there is no way to futz
around with your metadata.

Think filename completion, bash style. No, not just bash uses this.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 vs politics: linux misses out again

[Horst von Brand]

Ed Cogburn <[EMAIL PROTECTED]> wrote:
> David Lang wrote:
> > On Fri, 8 Jul 2005, Ed Tomlinson wrote:

> >> No Flame from me.  One thing to remember is that Hans and friends
> >> _have_ supported R3 for years.

They let it fall into disrepair when they started work on 4.

> >>This is an undisputed fact.

Exactly.

> >>Second
> >> third parties have be able to add much function (like journaling)
> >> to R3 so the code must be sort of readable...

Why don't you check it? Wouldn't you much prefer if the original authors
(or somebody similarly initmate with the code) did mayor surgery on it?
Specially if it is something you depend on?

> >> With R4 they have created a new FS that is _fast_

Remains to be seen.

> >>   and _can_ do things
> >> no other FS can

Mostly useless things...

> >>  - I also expect they have written cleaner code...

Better check first.

> >> Why are we fighting about adding this sort of function to the kernel?

Because the filessytem experts in the kernel development crowd (and others)
have /serious/ problems with the ideas and the code?

> >> Yes it may not be the absolute best way to do things.  How many times
> >> has tcpip be rewritten for linux?  The answer is more than once.

So?

> >> Lets put R4 in, see how it works, generalize the ideas and if we have
> >> to rewrite and rethink part of it lets do so.

Why not: Let's keep it out, fix the problems that it has and evaluate it
for inclusion once the problems have been ironed out?  That has been the
policy for everything else as far as I can remember (and that is from
nearly the beginning...)

> > remember that Hans is on record (over a year ago) arguing that R3 should
> > not be fixed becouse R4 was replacing it.

> > This type of thing is one of the reasons that you see arguments that
> > aren't 'purely code-related' becouse the kernel folks realize that _they_
> > will have to maintain the code over time, Hans and company will go on and
> > develop R5 (R10, whatever) and consider R4 obsolete and stop maintaining
> > it.

> Maybe its because Hans and Co., having only a finite amount of dev time,
> would much prefer to spend that time on R4 rather than R3?

ext2 is still being maintained alongside ext3.
 
>Maybe if we
> were to let R4 into the kernel, it wouldn't be long after that R3 could be
> retired because everyone has moved to R4?

ext3 is several years old, and there are /still/ ext2 users around...

[...]

> Devs should be free to work on whatever they want, because most of them are
> doing this on their own time anyway, otherwise they might just decide to
> hack on some other OS, or a fork of Linux instead.

Nobody forces anybody to work on Linux, or even on the standard Linus
kernel. It is the ReiserFS crowd who are demanding something from the Linux
crowd, not the other way around.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 vs politics: linux misses out again

[Horst von Brand]

Ed Cogburn [EMAIL PROTECTED] wrote:
 David Lang wrote:
  On Fri, 8 Jul 2005, Ed Tomlinson wrote:

  No Flame from me.  One thing to remember is that Hans and friends
  _have_ supported R3 for years.

They let it fall into disrepair when they started work on 4.

 This is an undisputed fact.

Exactly.

 Second
  third parties have be able to add much function (like journaling)
  to R3 so the code must be sort of readable...

Why don't you check it? Wouldn't you much prefer if the original authors
(or somebody similarly initmate with the code) did mayor surgery on it?
Specially if it is something you depend on?

  With R4 they have created a new FS that is _fast_

Remains to be seen.

and _can_ do things
  no other FS can

Mostly useless things...

   - I also expect they have written cleaner code...

Better check first.

  Why are we fighting about adding this sort of function to the kernel?

Because the filessytem experts in the kernel development crowd (and others)
have /serious/ problems with the ideas and the code?

  Yes it may not be the absolute best way to do things.  How many times
  has tcpip be rewritten for linux?  The answer is more than once.

So?

  Lets put R4 in, see how it works, generalize the ideas and if we have
  to rewrite and rethink part of it lets do so.

Why not: Let's keep it out, fix the problems that it has and evaluate it
for inclusion once the problems have been ironed out?  That has been the
policy for everything else as far as I can remember (and that is from
nearly the beginning...)

  remember that Hans is on record (over a year ago) arguing that R3 should
  not be fixed becouse R4 was replacing it.

  This type of thing is one of the reasons that you see arguments that
  aren't 'purely code-related' becouse the kernel folks realize that _they_
  will have to maintain the code over time, Hans and company will go on and
  develop R5 (R10, whatever) and consider R4 obsolete and stop maintaining
  it.

 Maybe its because Hans and Co., having only a finite amount of dev time,
 would much prefer to spend that time on R4 rather than R3?

ext2 is still being maintained alongside ext3.
 
Maybe if we
 were to let R4 into the kernel, it wouldn't be long after that R3 could be
 retired because everyone has moved to R4?

ext3 is several years old, and there are /still/ ext2 users around...

[...]

 Devs should be free to work on whatever they want, because most of them are
 doing this on their own time anyway, otherwise they might just decide to
 hack on some other OS, or a fork of Linux instead.

Nobody forces anybody to work on Linux, or even on the standard Linus
kernel. It is the ReiserFS crowd who are demanding something from the Linux
crowd, not the other way around.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

Hans Reiser <[EMAIL PROTECTED]> wrote:

[...]

> I think the exokernel approach by Frans is a very interesting approach. 
> I wish I had the experience with it necessary to know if it was
> effective.  I do NOT take the position that name resolution should be in
> the kernel.  I DO take the position that it should be either in the
> kernel or out of the kernel, and should constitute one cohesive and
> coherent body of code.

Right.

> If someone talks Linus into trying the exokernel
> approach,

Are you nuts?! Such radical experiments do /not/ belong in the kernel on
which millions of machines depend!

Go and fork off a branch to play around with this, and if it does show real
promise, you can then come back and try to integrate this into the official
kernel.

>   I will be happy to educate myself to where I have an opinion
> on whether that works.  It is easy to see powerful advantages to the
> exokernel approach: I wish I understood the security model for it, and I
> wish I was sure that name resolution would not require too many context
> switches as one fetches each storage component required by a name
> resolution.

Exactly the kinds of questions that have to get solid answers before any
experimental patches can get off the ground.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

Hubert Chan <[EMAIL PROTECTED]> wrote:
> On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs <[EMAIL PROTECTED]> said:
> > On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
> >> Hubert Chan wrote:
> >>> And a question: is it feasible to store, for each
> >>> inode, its parent(s), instead of just the hard link count?

> >> Ooh, now that is an interesting old idea I haven't considered in 20
> >> years makes fsck more robust too

> If you can store the parents, then finding cycles (relatively) quickly
> is pretty easy: before you try to make A the parent of B, walk up the
> parent pointers starting from A.  If you ever reach B, you have a cycle.
> If not, you don't have a cycle.  (Hmmm.  Do I need a proof of
> correctness for this?  It's just depth-first-search, which everybody
> learned in their first algorithms course.)

Correct. And you need space for potentially a huge lot of up pointers for
each file. And then there is the (very minor) problem is that meanwhile
/nothing/ can touch the filesystem to do any change...

How do you delete such an object? You will have to delete from each child
down to the first object that has a pointer to it from the outside, if you
don't want garbage left behind. And that means walking down to /each/
reachable object, then walking up from there to see if all its parents are
in the DAG rooted at what you are going to delete. This means potentially
walking through the whole filesystem (if you want to delete the root, or
something near). You will run out of memory, and again, meanwhile no
changes can be allowed.

It is for a reason that Unix filesystems don't have up pointers for files,
and just leaves (i.e., files) can have multiple hard links.

And this /was/ explained in detail the last flamefest over this exact same
point. I thought the ReiserFS people had learned from that...
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

David Masover <[EMAIL PROTECTED]> wrote:

[...]

> Just don't allow user-created hardlinks inside either metafs (/meta) or
> the magical meta directory inside files.

And what is it useful for, after its advantage was that it was /exactly/
like regular files , and now it is severely crippled?
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

Hubert Chan <[EMAIL PROTECTED]> wrote:
> On Fri, 01 Jul 2005 03:41:00 -0400, Chet Hosey <[EMAIL PROTECTED]> said:
> > Horst von Brand wrote:
> >> And who says that a normal user isn't allowed to annotate each and
> >> every file with its purpose or something else?

> Explain how you currently allow users to annotate arbitrary files.

By keeping annotations /outside/ the files.

[...]

> The situation is even better with file-as-dir.  If the administrator
> wants to allow users to edit the description metadata for the file foo,
> the administrator can set the appropriate permissions for
> foo/.../description, and keep foo read-only.

So now root is responsible in exquisite detail for random other users being
able to keep info about my files?

[...]

> Actually, you could use something like unionfs to allow users to keep
> their own annotations without affecting everyone else's.

Again, root has to mount that stuff for each and every user?
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

Hubert Chan [EMAIL PROTECTED] wrote:
 On Fri, 01 Jul 2005 03:41:00 -0400, Chet Hosey [EMAIL PROTECTED] said:
  Horst von Brand wrote:
  And who says that a normal user isn't allowed to annotate each and
  every file with its purpose or something else?

 Explain how you currently allow users to annotate arbitrary files.

By keeping annotations /outside/ the files.

[...]

 The situation is even better with file-as-dir.  If the administrator
 wants to allow users to edit the description metadata for the file foo,
 the administrator can set the appropriate permissions for
 foo/.../description, and keep foo read-only.

So now root is responsible in exquisite detail for random other users being
able to keep info about my files?

[...]

 Actually, you could use something like unionfs to allow users to keep
 their own annotations without affecting everyone else's.

Again, root has to mount that stuff for each and every user?
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

David Masover [EMAIL PROTECTED] wrote:

[...]

 Just don't allow user-created hardlinks inside either metafs (/meta) or
 the magical meta directory inside files.

And what is it useful for, after its advantage was that it was /exactly/
like regular files c, and now it is severely crippled?
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

Hubert Chan [EMAIL PROTECTED] wrote:
 On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs [EMAIL PROTECTED] said:
  On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
  Hubert Chan wrote:
  And a question: is it feasible to store, for each
  inode, its parent(s), instead of just the hard link count?

  Ooh, now that is an interesting old idea I haven't considered in 20
  years makes fsck more robust too

 If you can store the parents, then finding cycles (relatively) quickly
 is pretty easy: before you try to make A the parent of B, walk up the
 parent pointers starting from A.  If you ever reach B, you have a cycle.
 If not, you don't have a cycle.  (Hmmm.  Do I need a proof of
 correctness for this?  It's just depth-first-search, which everybody
 learned in their first algorithms course.)

Correct. And you need space for potentially a huge lot of up pointers for
each file. And then there is the (very minor) problem is that meanwhile
/nothing/ can touch the filesystem to do any change...

How do you delete such an object? You will have to delete from each child
down to the first object that has a pointer to it from the outside, if you
don't want garbage left behind. And that means walking down to /each/
reachable object, then walking up from there to see if all its parents are
in the DAG rooted at what you are going to delete. This means potentially
walking through the whole filesystem (if you want to delete the root, or
something near). You will run out of memory, and again, meanwhile no
changes can be allowed.

It is for a reason that Unix filesystems don't have up pointers for files,
and just leaves (i.e., files) can have multiple hard links.

And this /was/ explained in detail the last flamefest over this exact same
point. I thought the ReiserFS people had learned from that...
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

Hans Reiser [EMAIL PROTECTED] wrote:

[...]

 I think the exokernel approach by Frans is a very interesting approach. 
 I wish I had the experience with it necessary to know if it was
 effective.  I do NOT take the position that name resolution should be in
 the kernel.  I DO take the position that it should be either in the
 kernel or out of the kernel, and should constitute one cohesive and
 coherent body of code.

Right.

 If someone talks Linus into trying the exokernel
 approach,

Are you nuts?! Such radical experiments do /not/ belong in the kernel on
which millions of machines depend!

Go and fork off a branch to play around with this, and if it does show real
promise, you can then come back and try to integrate this into the official
kernel.

   I will be happy to educate myself to where I have an opinion
 on whether that works.  It is easy to see powerful advantages to the
 exokernel approach: I wish I understood the security model for it, and I
 wish I was sure that name resolution would not require too many context
 switches as one fetches each storage component required by a name
 resolution.

Exactly the kinds of questions that have to get solid answers before any
experimental patches can get off the ground.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Why cannot I do "insmod nfsd.ko" directly?

[Horst von Brand]

Xin Zhao <[EMAIL PROTECTED]> wrote:
> I tried to do "insmod nfsd.ko", but always got the error message
> "insmod: error inserting 'nfsd.ko': -1 Unknown symbol in module"

Use modprobe(8), it knows about module dependencies and what to load.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: i386: kill !4KSTACKS

[Horst von Brand]

Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> > > > > NB: gcc 3.4.3 can use excessive stack in degenerate cases, so please
> > > > > include gcc version in your reports.
> > > > 
> > > > But this can't occur in the kernel.
> > > 
> > > It can. I saw the OOPS myself.
> > > One of the functions in crypto/wp512.c was compiled with 3k+ stack usage.
> > 
> > Strange that "make checkstack" didn't show this.
> 
> It happens with certain gcc versions only.

Which ones, exactly? If they break this way, a workaround (or forbidding
them) would be the way to go...
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: i386: kill !4KSTACKS

[Horst von Brand]

Denis Vlasenko [EMAIL PROTECTED] wrote:
 NB: gcc 3.4.3 can use excessive stack in degenerate cases, so please
 include gcc version in your reports.

But this can't occur in the kernel.
   
   It can. I saw the OOPS myself.
   One of the functions in crypto/wp512.c was compiled with 3k+ stack usage.
  
  Strange that make checkstack didn't show this.
 
 It happens with certain gcc versions only.

Which ones, exactly? If they break this way, a workaround (or forbidding
them) would be the way to go...
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Why cannot I do insmod nfsd.ko directly?

[Horst von Brand]

Xin Zhao [EMAIL PROTECTED] wrote:
 I tried to do insmod nfsd.ko, but always got the error message
 insmod: error inserting 'nfsd.ko': -1 Unknown symbol in module

Use modprobe(8), it knows about module dependencies and what to load.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

David Masover <[EMAIL PROTECTED]> wrote:
> Horst von Brand wrote:
> > David Masover <[EMAIL PROTECTED]> wrote:
> >>David Weinehall wrote:
> >>>On Fri, Jul 01, 2005 at 03:08:58AM -0500, David Masover wrote:
> >>>>David Weinehall wrote:

[...]

> >>Even if they don't, it would be more beneficial to me

> > How, exactly?

> Go back and read.

I have. And have seen /no/ benefit to you. Except, of course, the benefit
accrued from some magic in Linus' kernel, by which all format differences
go in a puff of smoke if they are implemented inside it, and furthermore
all userland gets rebuilt to use the kernel's way overnight.

Sorry, I'm quite sceptical on this count. Sure, for complete outsiders it
may look that way: Something gets implemented in the kernel, soon many
applications are using it, everything is peachy. Except that before there
have been /long/ (even bitter) discussions on if/how to do it, what the
kernel should do (if anything) and what the application's responsibility
should be. Many times it has ended with Linus slamming on the table and
saying "no way", or "we do it /this/ way". Then, /when/ this is clear, it
gets into the kernel and applications. And you only have ever seen the last
phase... which is smooth and fast.

Here, the "how should it be done, if at all" discussion has barely started.
And AFAICS there are plenty of ways of getting 95% of the advantages
/without/ touching the kernel, so that should be the path to follow. Nobody
has shown any real evidence at all for this not being so.

> > Besides, /your/ convenience isn't the only thing that matters...

> Nor yours.

Sure enough.

>Just because you can't get your mind around a concept
> doesn't mean that it's a bad concept, and that no one else can use it.

I /do/ get my mind around the concept, it /is/ sometimes useful. It /can/
be done without the kernel, and so /should/ be done that way. That is all.

> >>  and probably
> >>most Linux users

> > "Most Linux users" don't use experimental filesystems at all...

> Actually, they do -- ext3 was experimental once.

Right. And ext2, and ext, and xiafs, and ... So? When they were
experimental, only a handful of utter fools commited their data to them.

>   ReiserFS was very
> experimental once.

See above.

> Please stop bashing it just because it's new/experimental.

Sorry?

> >> to have metafs supported in both GNOME and KDE, even
> >>if they still need an emulation layer to support other systems.
> > So Gnome and KDE get larger (and thus slower) for everybody.

> Smaller (and thus faster) on supported systems,

Sorry, but just because some $DISTRO gives ReiserFS4 as an /option/ doesn't
mean they will have everything duplicated as "For ReiserFS4" and "For other
filesystems". My assertion stands, until there are ReiserFS4-only
distributions.

> otherwise exactly the
> same, but maybe a little more modular, which is good.

Right, having to cope with different ways of representing metadata could
induce better code organization. But to get there isn't painless either...

> > Besides, Gnome
> > and KDE will have to agree on the formats involved first, which is /exactly/
> > what is supposed to be impossible unless this stuff is implemented in the
> > kernel...

> I never said that,

You (and others) have told us time and again that each of them have their
own incompatible ways of handling metadata, and that only if this was
handled in the kernel they would make use of a common way of managing it...

>but for one thing, whether they do or not, it's
> nice if my shell and my editor and all the other things that I use
> don't have to agree on anything to manipulate the formats involved.

Please, read what you just said. Everybody (kernel somewhat included) will
have to agree on the format of the metadata.

> This is not just about GNOME/KDE.  It is about GNOME/KDE not developing
> an additional layer, that you wouldn't like anyway,

How do you know what I would or would not like?

> that cannot be
> accessed from anything except GNOME/KDE.

So Gnome and KDE agree on some secret formats that only they can handle?
Behind their user's backs? As open source? And happily shoot their feet by
not giving users much wanted access to said data in decent ways?

I see it more on the lines of libmetadata.so (or such), which is used by
Gnome, KDE, and whatever else wishes to do so. Even your custom-tailored
shell or cat(1). Or just some convention that metadata on ~/my/funky/file
resides in ~/.metadat

Re: reiser4 plugins

[Horst von Brand]

David Masover [EMAIL PROTECTED] wrote:
 Horst von Brand wrote:
  David Masover [EMAIL PROTECTED] wrote:
 David Weinehall wrote:
 On Fri, Jul 01, 2005 at 03:08:58AM -0500, David Masover wrote:
 David Weinehall wrote:

[...]

 Even if they don't, it would be more beneficial to me

  How, exactly?

 Go back and read.

I have. And have seen /no/ benefit to you. Except, of course, the benefit
accrued from some magic in Linus' kernel, by which all format differences
go in a puff of smoke if they are implemented inside it, and furthermore
all userland gets rebuilt to use the kernel's way overnight.

Sorry, I'm quite sceptical on this count. Sure, for complete outsiders it
may look that way: Something gets implemented in the kernel, soon many
applications are using it, everything is peachy. Except that before there
have been /long/ (even bitter) discussions on if/how to do it, what the
kernel should do (if anything) and what the application's responsibility
should be. Many times it has ended with Linus slamming on the table and
saying no way, or we do it /this/ way. Then, /when/ this is clear, it
gets into the kernel and applications. And you only have ever seen the last
phase... which is smooth and fast.

Here, the how should it be done, if at all discussion has barely started.
And AFAICS there are plenty of ways of getting 95% of the advantages
/without/ touching the kernel, so that should be the path to follow. Nobody
has shown any real evidence at all for this not being so.

  Besides, /your/ convenience isn't the only thing that matters...

 Nor yours.

Sure enough.

Just because you can't get your mind around a concept
 doesn't mean that it's a bad concept, and that no one else can use it.

I /do/ get my mind around the concept, it /is/ sometimes useful. It /can/
be done without the kernel, and so /should/ be done that way. That is all.

   and probably
 most Linux users

  Most Linux users don't use experimental filesystems at all...

 Actually, they do -- ext3 was experimental once.

Right. And ext2, and ext, and xiafs, and ... So? When they were
experimental, only a handful of utter fools commited their data to them.

   ReiserFS was very
 experimental once.

See above.

 Please stop bashing it just because it's new/experimental.

Sorry?

  to have metafs supported in both GNOME and KDE, even
 if they still need an emulation layer to support other systems.
  So Gnome and KDE get larger (and thus slower) for everybody.

 Smaller (and thus faster) on supported systems,

Sorry, but just because some $DISTRO gives ReiserFS4 as an /option/ doesn't
mean they will have everything duplicated as For ReiserFS4 and For other
filesystems. My assertion stands, until there are ReiserFS4-only
distributions.

 otherwise exactly the
 same, but maybe a little more modular, which is good.

Right, having to cope with different ways of representing metadata could
induce better code organization. But to get there isn't painless either...

  Besides, Gnome
  and KDE will have to agree on the formats involved first, which is /exactly/
  what is supposed to be impossible unless this stuff is implemented in the
  kernel...

 I never said that,

You (and others) have told us time and again that each of them have their
own incompatible ways of handling metadata, and that only if this was
handled in the kernel they would make use of a common way of managing it...

but for one thing, whether they do or not, it's
 nice if my shell and my editor and all the other things that I use
 don't have to agree on anything to manipulate the formats involved.

Please, read what you just said. Everybody (kernel somewhat included) will
have to agree on the format of the metadata.

 This is not just about GNOME/KDE.  It is about GNOME/KDE not developing
 an additional layer, that you wouldn't like anyway,

How do you know what I would or would not like?

 that cannot be
 accessed from anything except GNOME/KDE.

So Gnome and KDE agree on some secret formats that only they can handle?
Behind their user's backs? As open source? And happily shoot their feet by
not giving users much wanted access to said data in decent ways?

I see it more on the lines of libmetadata.so (or such), which is used by
Gnome, KDE, and whatever else wishes to do so. Even your custom-tailored
shell or cat(1). Or just some convention that metadata on ~/my/funky/file
resides in ~/.metadata/.my/.funky/.file/metadata. Hey, you could (almost)
do that today, by wrappers (perhaps even aliases, or shell functions)
around the relevant commands! No kernel at all involved! Not even a
miserable library!!
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431

Re: ia64 git pull

[Horst von Brand]

Petr Baudis <[EMAIL PROTECTED]> said:

[...]

> The way to work around that is to setup separate rsync URIs for each of
> the trees. ;-) I think I will make git-pasky (Cogito) accept also URIs
> in form
> 
>   rsync://host/path!branchname
> 
> which will allow you to select the particular branch in the given
> repository, defaulting to the "master" branch.

Please don't use '!', several bash(1) versions just can't seem to get the
fact that '!' is quoted and try to do history expansion all over the place.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia64 git pull

[Horst von Brand]

Petr Baudis [EMAIL PROTECTED] said:

[...]

 The way to work around that is to setup separate rsync URIs for each of
 the trees. ;-) I think I will make git-pasky (Cogito) accept also URIs
 in form
 
   rsync://host/path!branchname
 
 which will allow you to select the particular branch in the given
 repository, defaulting to the master branch.

Please don't use '!', several bash(1) versions just can't seem to get the
fact that '!' is quoted and try to do history expansion all over the place.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: More performance for the TCP stack by using additional hardware chip on NIC

[Horst von Brand]

Andreas Hartmann <[EMAIL PROTECTED]> said:
> Alacritech developed a new chip for NIC's
> (http://www.alacritech.com/html/tech_review.html), which makes it possible
> to take away the TCP stack from the host CPU. Therefore, the host CPU has
> more performance for the applications according Alacritech.
> 
> This sounds interesting.

This idea has been discussed around here a couple of times, and the
consensus is that it is a bad idea: IP (and upper protocol) processing
is not expensive, if done right, so this really doesn't buy much; this
forces a particular interface to networking into the kernel, loosing
flexibility that way is always bad; there is no access to futzing
around in between (for example, for firewalling and such); and if the
"hardware implementation" has bugs, you are screwed.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: More performance for the TCP stack by using additional hardware chip on NIC

[Horst von Brand]

Andreas Hartmann [EMAIL PROTECTED] said:
 Alacritech developed a new chip for NIC's
 (http://www.alacritech.com/html/tech_review.html), which makes it possible
 to take away the TCP stack from the host CPU. Therefore, the host CPU has
 more performance for the applications according Alacritech.
 
 This sounds interesting.

This idea has been discussed around here a couple of times, and the
consensus is that it is a bad idea: IP (and upper protocol) processing
is not expensive, if done right, so this really doesn't buy much; this
forces a particular interface to networking into the kernel, loosing
flexibility that way is always bad; there is no access to futzing
around in between (for example, for firewalling and such); and if the
hardware implementation has bugs, you are screwed.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [INFO] Kernel strict versioning

[Horst von Brand]

"Franco \"Sensei\"" <[EMAIL PROTECTED]> said:
> David Lang wrote:
> > some config changes are additions, some redefine things.
> > 
> > you are mistakeing the .config file for a symbol table.

> No I'm not confusing. As long as the .config has an influence on the 
> makefiles I get different symbols names.

Nope.

> > for example if you compile a kernel with SMP=y you get different code 
> > then if you compile with SMP=n
> > 
> > if you have the same kernel version on identical machines, but with the 
> > SMP option different on the two different machines you cannot use the 
> > same module binary on both of them.

> Of course, but It's cleare that machines with SMP are different from a 
> simple mono-cpu.

And kernels compiled with one compiler are different than those compiled
with another. And if you have preemption they are different. Don't forget
about clasic i386 vs i486 vs ... vs i686 (spinlocks generate different
code!). Then let's consider memory split: 2/2, 3/1, 3.5/0.5, ... Now throw
in assorted debugging options. On some architectures you have several
possible (reasonable!) page sizes.

> It's not an issue talking about smp vs. not-smp. Let's talk about a 
> machine: it's useless arguing about Cray while I'm talking about a 
> simple environment.

Define "simple environment". Even Red Hat (they are /very/ interested in a
single kernel image, as it cuts down testing and bug tracking etc!) ships
half a dozen different kernels, tailored for different configurations. And
you'll find external modules (like for NTFS) compiled separately for each
of them.

> Every kernel has always the distinction about smp. So it's not a big 
> problem.

And it has distinctions on dozens of other configuration options too.

[...]

> Finding a bug in the kernel source and patching it, must be a careful 
> step, because if I have to mantain 100 machines, and I know that 
> applying the patch will result in a broken kernel modules, I'm not happy 
> with it. I must go manually on each machine, apply the patch, recompile 
> the modules... Makes me think about NOT applying the patch.

Or having /your/ standard kernel on all 100 machines, compile once and copy
around. No need for /me/ to run your exact same configuration.

[...]

> Source compatibility is there.

Sort of.

>Now, you're talking about issues which 
> are not your buisness: a binary distribution must take care of how the
> kernel it's compiled. As long as it uses the same gcc and switches, it's
> ok.

Yes, it is their bussiness.

> Practically, if suse has kernel-2.6.A and kernel-modules-2.6.A it knows 
> how they're compiled, and they work everywhere. Of course, it has also 
> kernel-2.6.A-SMP and its modules.

And A doesn't have some options I'd like, and others you loathe.

> When 2.6.B is released, using ABI will just result in another 
> compilation,

Right.

>  creating the kernel with additions and patches, and 
> distributing them. Modules .A should work on .B,

Iff nothing changes. That isn't usually the case.

>  like I do with OpenAFS, 
> Every kernel update shouldn't break the magic :)

The problem is that giving that guarantee costs developer time and
flexibility. The gain (given that source for recompilation is freely
available) is so minuscule that the consensus is that it just isn't worth
any extra hassle /at all/.

> > but 2.6.11.7 is not nessasarily binary compatable with 2.6.11.7, let 
> > alone something drasticly different (say 2.6.11.6)

> Sure, because it's not designed to be so.

And the decision to design thusly is completely conscicious, it is not a
random "it just turned out this way by mistake".

> I just see advantages on ABI, and I think it's not bad talking about it...

I see many disadvantages to ABI, and it wouldn't be bad to look at them too.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [INFO] Kernel strict versioning

[Horst von Brand]

Franco \Sensei\ [EMAIL PROTECTED] said:
 David Lang wrote:
  some config changes are additions, some redefine things.
  
  you are mistakeing the .config file for a symbol table.

 No I'm not confusing. As long as the .config has an influence on the 
 makefiles I get different symbols names.

Nope.

  for example if you compile a kernel with SMP=y you get different code 
  then if you compile with SMP=n
  
  if you have the same kernel version on identical machines, but with the 
  SMP option different on the two different machines you cannot use the 
  same module binary on both of them.

 Of course, but It's cleare that machines with SMP are different from a 
 simple mono-cpu.

And kernels compiled with one compiler are different than those compiled
with another. And if you have preemption they are different. Don't forget
about clasic i386 vs i486 vs ... vs i686 (spinlocks generate different
code!). Then let's consider memory split: 2/2, 3/1, 3.5/0.5, ... Now throw
in assorted debugging options. On some architectures you have several
possible (reasonable!) page sizes.

 It's not an issue talking about smp vs. not-smp. Let's talk about a 
 machine: it's useless arguing about Cray while I'm talking about a 
 simple environment.

Define simple environment. Even Red Hat (they are /very/ interested in a
single kernel image, as it cuts down testing and bug tracking etc!) ships
half a dozen different kernels, tailored for different configurations. And
you'll find external modules (like for NTFS) compiled separately for each
of them.

 Every kernel has always the distinction about smp. So it's not a big 
 problem.

And it has distinctions on dozens of other configuration options too.

[...]

 Finding a bug in the kernel source and patching it, must be a careful 
 step, because if I have to mantain 100 machines, and I know that 
 applying the patch will result in a broken kernel modules, I'm not happy 
 with it. I must go manually on each machine, apply the patch, recompile 
 the modules... Makes me think about NOT applying the patch.

Or having /your/ standard kernel on all 100 machines, compile once and copy
around. No need for /me/ to run your exact same configuration.

[...]

 Source compatibility is there.

Sort of.

Now, you're talking about issues which 
 are not your buisness: a binary distribution must take care of how the
 kernel it's compiled. As long as it uses the same gcc and switches, it's
 ok.

Yes, it is their bussiness.

 Practically, if suse has kernel-2.6.A and kernel-modules-2.6.A it knows 
 how they're compiled, and they work everywhere. Of course, it has also 
 kernel-2.6.A-SMP and its modules.

And A doesn't have some options I'd like, and others you loathe.

 When 2.6.B is released, using ABI will just result in another 
 compilation,

Right.

  creating the kernel with additions and patches, and 
 distributing them. Modules .A should work on .B,

Iff nothing changes. That isn't usually the case.

  like I do with OpenAFS, 
 Every kernel update shouldn't break the magic :)

The problem is that giving that guarantee costs developer time and
flexibility. The gain (given that source for recompilation is freely
available) is so minuscule that the consensus is that it just isn't worth
any extra hassle /at all/.

  but 2.6.11.7 is not nessasarily binary compatable with 2.6.11.7, let 
  alone something drasticly different (say 2.6.11.6)

 Sure, because it's not designed to be so.

And the decision to design thusly is completely conscicious, it is not a
random it just turned out this way by mistake.

 I just see advantages on ABI, and I think it's not bad talking about it...

I see many disadvantages to ABI, and it wouldn't be bad to look at them too.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2/8] correctly name the Shell sort

[Horst von Brand]

[EMAIL PROTECTED] said:

> As per http://www.nist.gov/dads/HTML/shellsort.html, this should be
> referred to as a Shell sort. Shell-Metzner is a misnomer.

> Signed-off-by: Daniel Dickman <[EMAIL PROTECTED]>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>

Why not use the sort routine from lib/sort.c?
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2/8] correctly name the Shell sort

[Horst von Brand]

[EMAIL PROTECTED] said:

 As per http://www.nist.gov/dads/HTML/shellsort.html, this should be
 referred to as a Shell sort. Shell-Metzner is a misnomer.

 Signed-off-by: Daniel Dickman [EMAIL PROTECTED]
 Signed-off-by: Domen Puncer [EMAIL PROTECTED]

Why not use the sort routine from lib/sort.c?
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][RFC] disable built-in modules V2

[Horst von Brand]

AsterixTheGaul <[EMAIL PROTECTED]> said:
> > -#define module_init(x) __initcall(x);
> > +#define module_init(x) __initcall(x); __module_init_disable(x);
> 
> It would be better if there is brackets around them... like
> 
> #define module_init(x) { __initcall(x); __module_init_disable(x); }
> 
> then we know it wont break some code like
> 
> if (..)
>  module_init(x);

But happily break:

   if (...)
module_init(x);
   else
...

This should be:

#define module_init(x)  do {__initcall(x); __module_init_disable(x);}while(0)
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][RFC] disable built-in modules V2

[Horst von Brand]

AsterixTheGaul [EMAIL PROTECTED] said:
  -#define module_init(x) __initcall(x);
  +#define module_init(x) __initcall(x); __module_init_disable(x);
 
 It would be better if there is brackets around them... like
 
 #define module_init(x) { __initcall(x); __module_init_disable(x); }
 
 then we know it wont break some code like
 
 if (..)
  module_init(x);

But happily break:

   if (...)
module_init(x);
   else
...

This should be:

#define module_init(x)  do {__initcall(x); __module_init_disable(x);}while(0)
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Horst von Brand]

Sven Luther <[EMAIL PROTECTED]> said:
> On Tue, Apr 05, 2005 at 08:16:48AM -0400, Jeff Garzik wrote:
> > Humberto Massa wrote:
> > >But, the question made here was a subtler one and you are all biting 
> > >around the bush: there *are* some misrepresentations of licenses to the 
> > >firmware blobs in the kernel (-- ok, *if* you consider that hex dumps 
> > >are not source code). What Sven asked was: "Hey, can I state explicitly 
> > >the distribution state in the source files, by means of adding some 
> > >comments?".
> > 
> > >I think even a clarification "this firmware hexdump is considered to be 
> > >the source code, and it's GPL'd" would do, but I must put my asbestos 
> > >suit everytime I say it. :-)
> > 
> > We do not add comments to the kernel source code which simply state the 
> > obvious.
> 
> The only thing here is that it has to be obvious not only to you, but to the
> judge too :)
> 
> In this case, it is not comments, but proper copyright attribution, which was
> added in the tg3.c case since the first checkin :
> 
> /*
>  * tg3.c: Broadcom Tigon3 ethernet driver.
>  *
>  * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem@redhat.com)
>  * Copyright (C) 2001, 2002, 2003 Jeff Garzik ([EMAIL PROTECTED])
>  * Copyright (C) 2004 Sun Microsystems Inc.
>  *
>  * Firmware is:
>  *  Copyright (C) 2000-2003 Broadcom Corporation.
>  */
> 
> The firmware part was not present in the original checkin you did in 2002.
> Adding something about the licencing status of it would be enough.
> 
> Or even adding some comment in the toplevel COPYING file saying that firmware
> blobs come under their own licence or something such, and then listing all the
> firmware blobs and their licencing condition in a separate toplevel file would
> be enough.
> 
> Friendly,
> 
> Sven Luther
> 
> -
> 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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Horst von Brand]

Sven Luther [EMAIL PROTECTED] said:
 On Tue, Apr 05, 2005 at 08:16:48AM -0400, Jeff Garzik wrote:
  Humberto Massa wrote:
  But, the question made here was a subtler one and you are all biting 
  around the bush: there *are* some misrepresentations of licenses to the 
  firmware blobs in the kernel (-- ok, *if* you consider that hex dumps 
  are not source code). What Sven asked was: Hey, can I state explicitly 
  the distribution state in the source files, by means of adding some 
  comments?.
  
  I think even a clarification this firmware hexdump is considered to be 
  the source code, and it's GPL'd would do, but I must put my asbestos 
  suit everytime I say it. :-)
  
  We do not add comments to the kernel source code which simply state the 
  obvious.
 
 The only thing here is that it has to be obvious not only to you, but to the
 judge too :)
 
 In this case, it is not comments, but proper copyright attribution, which was
 added in the tg3.c case since the first checkin :
 
 /*
  * tg3.c: Broadcom Tigon3 ethernet driver.
  *
  * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem@redhat.com)
  * Copyright (C) 2001, 2002, 2003 Jeff Garzik ([EMAIL PROTECTED])
  * Copyright (C) 2004 Sun Microsystems Inc.
  *
  * Firmware is:
  *  Copyright (C) 2000-2003 Broadcom Corporation.
  */
 
 The firmware part was not present in the original checkin you did in 2002.
 Adding something about the licencing status of it would be enough.
 
 Or even adding some comment in the toplevel COPYING file saying that firmware
 blobs come under their own licence or something such, and then listing all the
 firmware blobs and their licencing condition in a separate toplevel file would
 be enough.
 
 Friendly,
 
 Sven Luther
 
 -
 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/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: security issue: hard disk lock

[Horst von Brand]

Jonas Diemer <[EMAIL PROTECTED]> said:

[...]

> I figured there could be a kernel compiled-in option that will make the
> kernel lock all drives found during bootup. then, a malicous program
> would need to install a different kernel in order to harm the drive,
> which would be much more secure.

Doing it in initrd should be plenty of time, no need to involve the kernel.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFD] 'nice' attribute for executable files

[Horst von Brand]

Wiktor <[EMAIL PROTECTED]> said:
> Horst von Brand wrote:
> > Even better: Write a C wrapper for each affected program that just renices
> > it as needed.

> I suggest to implement scalable solution, so the final user wont't have 
> to write separate wrapper for *each* program.

Final user doesn't. It is a job for whoever writes the program, or packages
it for a distro. If even required.

>   universal wrapper is 
> better solution, but (now i know, that implementing something that can 
> be dangerous if used incorrectly is so evil, that only the devil could 
> have proposed it) it forces use of database (that normally would be kept 
> in filesystem's file metadata) and if some-malicious-person would have 
> accessed it in write mode (as result of wrong file permissions), the 
> system performerance would be in danger. in my solution, there is 
> per-file attribute, accessible only for root, and if hacker has root 
> permissions, existence of nice attribute is meaningless.

Anything like this that can be accessed by plain users (not root) is
inherently dangerous. It is for a reason that only root can increase the
priority of a process. If you allow reniceing and place some kind of limit
on it, even Aunt Tillie will run her programs with priority maxed out, and
we are back were we are today.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFD] 'nice' attribute for executable files

[Horst von Brand]

Wiktor [EMAIL PROTECTED] said:
 Horst von Brand wrote:
  Even better: Write a C wrapper for each affected program that just renices
  it as needed.

 I suggest to implement scalable solution, so the final user wont't have 
 to write separate wrapper for *each* program.

Final user doesn't. It is a job for whoever writes the program, or packages
it for a distro. If even required.

   universal wrapper is 
 better solution, but (now i know, that implementing something that can 
 be dangerous if used incorrectly is so evil, that only the devil could 
 have proposed it) it forces use of database (that normally would be kept 
 in filesystem's file metadata) and if some-malicious-person would have 
 accessed it in write mode (as result of wrong file permissions), the 
 system performerance would be in danger. in my solution, there is 
 per-file attribute, accessible only for root, and if hacker has root 
 permissions, existence of nice attribute is meaningless.

Anything like this that can be accessed by plain users (not root) is
inherently dangerous. It is for a reason that only root can increase the
priority of a process. If you allow reniceing and place some kind of limit
on it, even Aunt Tillie will run her programs with priority maxed out, and
we are back were we are today.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFD] 'nice' attribute for executable files

[Horst von Brand]

=?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <[EMAIL PROTECTED]> said:
> Wiktor <[EMAIL PROTECTED]> writes:

[...]

> > max renice ulimit is quite good idea, but it allows to change nice of
> > *any* process user has permissions to. it could be implemented also,
> > but the idea of 'nice' file attribute is to allow *only* some process
> > be run with lower nice. what's more, that nice would be *always* the
> > same (at process startup)!

> It can be done entirely in userspace, if you want it.  Just hack your
> shell to examine some extended attribute of your choice, and adjust
> the nice value before executing files.  Then arrange to have the shell
> run with a negative nice value.  This can be easily accomplished with
> a simple wrapper, only for the shell.

Even better: Write a C wrapper for each affected program that just renices
it as needed.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFD] 'nice' attribute for executable files

[Horst von Brand]

=?iso-8859-1?q?M=E5ns_Rullg=E5rd?= [EMAIL PROTECTED] said:
 Wiktor [EMAIL PROTECTED] writes:

[...]

  max renice ulimit is quite good idea, but it allows to change nice of
  *any* process user has permissions to. it could be implemented also,
  but the idea of 'nice' file attribute is to allow *only* some process
  be run with lower nice. what's more, that nice would be *always* the
  same (at process startup)!

 It can be done entirely in userspace, if you want it.  Just hack your
 shell to examine some extended attribute of your choice, and adjust
 the nice value before executing files.  Then arrange to have the shell
 run with a negative nice value.  This can be easily accomplished with
 a simple wrapper, only for the shell.

Even better: Write a C wrapper for each affected program that just renices
it as needed.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Do not misuse Coverity please

[Horst von Brand]

"Jean Delvare" <[EMAIL PROTECTED]> said:
> > > > No, there is a third case: the pointer can be NULL, but the compiler
> > > > happened to move the dereference down to after the check.

> > > Wow. Great point. I completely missed that possibility. In fact I didn't
> > > know that the compiler could possibly alter the order of the
> > > instructions. For one thing, I thought it was simply not allowed to. For
> > > another, I didn't know that it had been made so aware that it could
> > > actually figure out how to do this kind of things. What a mess. Let's
> > > just hope that the gcc folks know their business :)

> > The compiler is most definitely /not/ allowed to change the results the
> > code gives.

> I think that Andrew's point was that the compiler could change the order
> of the instructions *when this doesn't change the result*, not just in
> the general case, of course. In our example, The instructions:
> 
> v = p->field;
> if (!p) return;
> 
> can be seen as equivalent to
> 
> if (!p) return;
> v = p->field;

They are not. If p == NULL, the first gives an exception (SIGSEGV), the
second one doesn't. Just as you can't "optimize" by switching:

x = b / a;   
if (a == 0) return;
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Do not misuse Coverity please

[Horst von Brand]

Jean Delvare [EMAIL PROTECTED] said:
No, there is a third case: the pointer can be NULL, but the compiler
happened to move the dereference down to after the check.

   Wow. Great point. I completely missed that possibility. In fact I didn't
   know that the compiler could possibly alter the order of the
   instructions. For one thing, I thought it was simply not allowed to. For
   another, I didn't know that it had been made so aware that it could
   actually figure out how to do this kind of things. What a mess. Let's
   just hope that the gcc folks know their business :)

  The compiler is most definitely /not/ allowed to change the results the
  code gives.

 I think that Andrew's point was that the compiler could change the order
 of the instructions *when this doesn't change the result*, not just in
 the general case, of course. In our example, The instructions:
 
 v = p-field;
 if (!p) return;
 
 can be seen as equivalent to
 
 if (!p) return;
 v = p-field;

They are not. If p == NULL, the first gives an exception (SIGSEGV), the
second one doesn't. Just as you can't optimize by switching:

x = b / a;   
if (a == 0) return;
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)

[Horst von Brand]

"Jean Delvare" <[EMAIL PROTECTED]> said:

[Sttributions missing, sorry]

> > >  Think about it. If the pointer could be NULL, then it's unlikely that
> > >  the bug would have gone unnoticed so far (unless the code is very
> > >  recent). Coverity found 3 such bugs in one i2c driver [1], and the
> > >  correct solution was to NOT check for NULL because it just couldn't
> > >  happen.

> > No, there is a third case: the pointer can be NULL, but the compiler
> > happened to move the dereference down to after the check.

> Wow. Great point. I completely missed that possibility. In fact I didn't
> know that the compiler could possibly alter the order of the
> instructions. For one thing, I thought it was simply not allowed to. For
> another, I didn't know that it had been made so aware that it could
> actually figure out how to do this kind of things. What a mess. Let's
> just hope that the gcc folks know their business :)

The compiler is most definitely /not/ allowed to change the results the
code gives.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
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/