RE: Cosmetic JFFS patch.

2001-07-05 Thread Heusden, Folkert van

> Leave the copyright messages alone is all I can say. And as to your flag,
> well we've got one. Try the 'quiet' boot option
YOU> Leaving copyright messages also saves the purpose of motivating - not
all but
YOU> many - developers.  People who _see_ the printk copyright messages is a
_very_
YOU> large superset of people who _look_ at source code, or ChangeLog /
CREDITS /
YOU> MAINTAINERS files.
YOU> After all many copyright messages are not that annoying.

Suggestion: make the buffer-size for these messages configurable at make
config -time.
So; people can define wether they want the message or not. If size=0, the
printk-thing
could be replaced with
#define printk(x)  /*nothing*/
Nice for the embedded linux-system people.


Greetings,

Folkert van Heusden
[ www.vanheusden.com ]
-
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: Cosmetic JFFS patch.

2001-07-05 Thread Heusden, Folkert van

 Leave the copyright messages alone is all I can say. And as to your flag,
 well we've got one. Try the 'quiet' boot option
YOU Leaving copyright messages also saves the purpose of motivating - not
all but
YOU many - developers.  People who _see_ the printk copyright messages is a
_very_
YOU large superset of people who _look_ at source code, or ChangeLog /
CREDITS /
YOU MAINTAINERS files.
YOU After all many copyright messages are not that annoying.

Suggestion: make the buffer-size for these messages configurable at make
config -time.
So; people can define wether they want the message or not. If size=0, the
printk-thing
could be replaced with
#define printk(x)  /*nothing*/
Nice for the embedded linux-system people.


Greetings,

Folkert van Heusden
[ www.vanheusden.com ]
-
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: A signal fairy tale - a little comphist

2001-06-28 Thread Heusden, Folkert van

[...]
>A signal number cannot be opened more than once concurrently;
>sigopen() thus provides a way to avoid signal usage clashes
>in large programs.
YOU> Signals are a pretty dopey API anyway - 

Exactly. When signals were made up, signalhandlers were supposed to
not so much more then a last cry and then exit the application. sigHUP
to re-read the config was not supposed to happen.

YOU> so instead of trying to patch
YOU> them up, why not think of something better for AIO?

Yeah, a select() on excepfds.

-
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: A signal fairy tale - a little comphist

2001-06-28 Thread Heusden, Folkert van

[...]
A signal number cannot be opened more than once concurrently;
sigopen() thus provides a way to avoid signal usage clashes
in large programs.
YOU Signals are a pretty dopey API anyway - 

Exactly. When signals were made up, signalhandlers were supposed to
not so much more then a last cry and then exit the application. sigHUP
to re-read the config was not supposed to happen.

YOU so instead of trying to patch
YOU them up, why not think of something better for AIO?

Yeah, a select() on excepfds.

-
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: The Joy of Forking

2001-06-25 Thread Heusden, Folkert van

>>  x86 only (and similar, e.g. Crusoe)
> Again, Linux is the only system that CAN run on anything from PDA thorough
> supercomputer clusters.

What about NetBSD? :o)

-
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: The Joy of Forking

2001-06-25 Thread Heusden, Folkert van

  x86 only (and similar, e.g. Crusoe)
 Again, Linux is the only system that CAN run on anything from PDA thorough
 supercomputer clusters.

What about NetBSD? :o)

-
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: Client receives TCP packets but does not ACK

2001-06-15 Thread Heusden, Folkert van

> TCP is NOT a guaranteed protocol -- you can't just blast data from one
port
> to another and expect it to work.

Isn't it? Are you really sure about that? I thought UDP was the
not-guaranteed-one and TCP was the one guaranting that all data reaches the
other end in order and all. Please enlighten me.

-
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: Client receives TCP packets but does not ACK

2001-06-15 Thread Heusden, Folkert van

 TCP is NOT a guaranteed protocol -- you can't just blast data from one
port
 to another and expect it to work.

Isn't it? Are you really sure about that? I thought UDP was the
not-guaranteed-one and TCP was the one guaranting that all data reaches the
other end in order and all. Please enlighten me.

-
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 code must die

2001-06-14 Thread Heusden, Folkert van

Yeah, and while you're at it: make it closed source and ask big time $$
for every single line of update.
If your stupid idea will be followed, a lot of african people will not
be happy. (me neither. proud owner of a 486 (at home))

-Original Message-
From: Daniel [mailto:[EMAIL PROTECTED]]
Sent: donderdag 14 juni 2001 2:44
To: Linux kernel
Subject: obsolete code must die


Anyone concerned about the current size of the kernel source code? I am, and
I propose to start cleaning house on the x86 platform. I mean it's all very
well and good to keep adding features, but stuff needs to go if kernel
development is to move forward. Before listing the gunk I want to get rid
of, here's my justification for doing so:
-- Getting rid of old code can help simplify the kernel. This means less
chance of bugs.
-- Simplifying the kernel means that it will be easier for newbies to
understand and perhaps contribute.
-- a simpler, cleaner kernel will also be of more use in an academic
environment.
-- a smaller kernel is easier to maintain and is easier to re-architect
should the need arise.
-- If someone really needs support for this junk, they will always have the
option of using the 2.0.x, 2.2.x or 2.4.x series.

So without further ado here're the features I want to get rid of:

i386, i486
The Pentium processor has been around since 1995. Support for these older
processors should go so we can focus on optimizations for the pentium and
better processors.

math-emu
If support for i386 and i486 is going away, then so should math emulation.
Every intel processor since the 486DX has an FPU unit built in. In fact
shouldn't FPU support be a userspace responsibility anyway?

ISA bus, MCA bus, EISA bus
PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
CONFIG_ISAPNP, etc

ISA, MCA, EISA device drivers
If support for the buses is gone, there's no point in supporting devices for
these buses.

all code marked as CONFIG_OBSOLETE
Since we're cleaning house we may as well get rid of this stuff.

MFM/RLL/XT/ESDI hard drive support
Does anyone still *have* an RLL drive that works? At the very least get rid
of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE,
CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2)

parallel/serial/game ports
More controversial to remove this, since they are *still* in pretty wide
use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts.

a.out
Who needs it anymore. I love ELF.

I really think doing a clean up is worthwhile. Maybe while looking for stuff
to clean up we'll even be able to better comment the existing code. Any
other features people would like to get rid of? Any comments or suggestions?
I'd love to start a good discussion about this going so please send me your
2 cents.

Daniel

-
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: obsolete code must die

2001-06-14 Thread Heusden, Folkert van

Yeah, and while you're at it: make it closed source and ask big time $$
for every single line of update.
If your stupid idea will be followed, a lot of african people will not
be happy. (me neither. proud owner of a 486 (at home))

-Original Message-
From: Daniel [mailto:[EMAIL PROTECTED]]
Sent: donderdag 14 juni 2001 2:44
To: Linux kernel
Subject: obsolete code must die


Anyone concerned about the current size of the kernel source code? I am, and
I propose to start cleaning house on the x86 platform. I mean it's all very
well and good to keep adding features, but stuff needs to go if kernel
development is to move forward. Before listing the gunk I want to get rid
of, here's my justification for doing so:
-- Getting rid of old code can help simplify the kernel. This means less
chance of bugs.
-- Simplifying the kernel means that it will be easier for newbies to
understand and perhaps contribute.
-- a simpler, cleaner kernel will also be of more use in an academic
environment.
-- a smaller kernel is easier to maintain and is easier to re-architect
should the need arise.
-- If someone really needs support for this junk, they will always have the
option of using the 2.0.x, 2.2.x or 2.4.x series.

So without further ado here're the features I want to get rid of:

i386, i486
The Pentium processor has been around since 1995. Support for these older
processors should go so we can focus on optimizations for the pentium and
better processors.

math-emu
If support for i386 and i486 is going away, then so should math emulation.
Every intel processor since the 486DX has an FPU unit built in. In fact
shouldn't FPU support be a userspace responsibility anyway?

ISA bus, MCA bus, EISA bus
PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
CONFIG_ISAPNP, etc

ISA, MCA, EISA device drivers
If support for the buses is gone, there's no point in supporting devices for
these buses.

all code marked as CONFIG_OBSOLETE
Since we're cleaning house we may as well get rid of this stuff.

MFM/RLL/XT/ESDI hard drive support
Does anyone still *have* an RLL drive that works? At the very least get rid
of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE,
CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2)

parallel/serial/game ports
More controversial to remove this, since they are *still* in pretty wide
use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts.

a.out
Who needs it anymore. I love ELF.

I really think doing a clean up is worthwhile. Maybe while looking for stuff
to clean up we'll even be able to better comment the existing code. Any
other features people would like to get rid of? Any comments or suggestions?
I'd love to start a good discussion about this going so please send me your
2 cents.

Daniel

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



virus; do not open message with subject MAWANA

2001-05-23 Thread Heusden, Folkert van

(This message was BCC'd to multiple people)

Hi,

A sad event occured today; I accidently managed to get a virus sent trough
my pc.
Because of that, I'm sending this message to everyone in my addressbook
since I'm
not totally sure who got one (the virus), and who not.
I'll take all care that this won't happen again in the future.
For now; my deepest and most sincere apologies!


Greetings,

Folkert van Heusden
-
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/



virus; do not open message with subject MAWANA

2001-05-23 Thread Heusden, Folkert van

(This message was BCC'd to multiple people)

Hi,

A sad event occured today; I accidently managed to get a virus sent trough
my pc.
Because of that, I'm sending this message to everyone in my addressbook
since I'm
not totally sure who got one (the virus), and who not.
I'll take all care that this won't happen again in the future.
For now; my deepest and most sincere apologies!


Greetings,

Folkert van Heusden
-
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/



weird

2001-05-09 Thread Heusden, Folkert van

On my dual pii system, I get these messages:
May  9 15:53:18 marlboro.intranet.vanheusden.com kernel: KERNEL: assertion
(tp->lost_out == 0) failed at tcp_input.c(1202):tcp_remove_reno_sacks

Is this worrying?
More info:
marlboro:~$ uname -a
Linux marlboro 2.4.3 #4 SMP Sun May 6 13:23:49 GMT+1 2001 i686 unknown

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



weird

2001-05-09 Thread Heusden, Folkert van

On my dual pii system, I get these messages:
May  9 15:53:18 marlboro.intranet.vanheusden.com kernel: KERNEL: assertion
(tp-lost_out == 0) failed at tcp_input.c(1202):tcp_remove_reno_sacks

Is this worrying?
More info:
marlboro:~$ uname -a
Linux marlboro 2.4.3 #4 SMP Sun May 6 13:23:49 GMT+1 2001 i686 unknown

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



/dev/random - having a (trivial) coding problem

2001-05-07 Thread Heusden, Folkert van

See this program:

int main(int argc, char *argv[])
{
int h;
char buffer[16];
int nbytes=16,nbits=16*8;
int nin;

h=open("/dev/random", O_RDONLY);
if (h==-1) exit(1);

/* see how many bits there are in it */
printf("returned: %d\n", ioctl(h, RNDGETENTCNT, ));
printf("current number of bits: %d\n", nin);

/* add some */
printf("returned: %d\n", ioctl(h, RNDADDENTROPY, buffer, (int
*), (int *)));

/* see it it succeeded */
printf("returned: %d\n", ioctl(h, RNDGETENTCNT, ));
printf("current number of bits: %d\n", nin);

return 0;
}

it always fails!
But if I read the code for /dev/random correctly:
case RNDADDENTROPY:
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
p = (int *) arg;
if (get_user(ent_count, p++))
return -EFAULT;
if (ent_count < 0)
return -EINVAL;
if (get_user(size, p++))
return -EFAULT;
retval = random_write(file, (const char *) p,
  size, >f_pos);
if (retval < 0)
return retval;
credit_entropy_store(random_state, ent_count);

I did the right thing.
Didn't I? Aren't the ioctl-parameters in this case pointer to int, pointer
to int (ent_count) and another (to size)?
-
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/



/dev/random - having a (trivial) coding problem

2001-05-07 Thread Heusden, Folkert van

See this program:

int main(int argc, char *argv[])
{
int h;
char buffer[16];
int nbytes=16,nbits=16*8;
int nin;

h=open(/dev/random, O_RDONLY);
if (h==-1) exit(1);

/* see how many bits there are in it */
printf(returned: %d\n, ioctl(h, RNDGETENTCNT, nin));
printf(current number of bits: %d\n, nin);

/* add some */
printf(returned: %d\n, ioctl(h, RNDADDENTROPY, buffer, (int
*)nbits, (int *)nbytes));

/* see it it succeeded */
printf(returned: %d\n, ioctl(h, RNDGETENTCNT, nin));
printf(current number of bits: %d\n, nin);

return 0;
}

it always fails!
But if I read the code for /dev/random correctly:
case RNDADDENTROPY:
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
p = (int *) arg;
if (get_user(ent_count, p++))
return -EFAULT;
if (ent_count  0)
return -EINVAL;
if (get_user(size, p++))
return -EFAULT;
retval = random_write(file, (const char *) p,
  size, file-f_pos);
if (retval  0)
return retval;
credit_entropy_store(random_state, ent_count);

I did the right thing.
Didn't I? Aren't the ioctl-parameters in this case pointer to int, pointer
to int (ent_count) and another (to size)?
-
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/



RFC: pageable kernel-segments

2001-04-17 Thread Heusden, Folkert van

Would anyone be intrested (besides me) in a kernel which can page
out certain parts of itself? The kernel should be in some kind of
vmlinux-ish (as in: uncompressed) format on disk for on-demand
re-loading of pages which are discarded.
Certain parts of drivers could get the __pageable prefix or so
(like the __init parts of drivers which get removed) for letting
the paging-code know that it can be discared if memory-pressure
demands it.
__pageable -code would then be things like (e.g.!) the code which
handles the open()/close() of a device. Most of the time a device
spends more time doing read/write/ioctl then close/open so. Also;
hopefully there's no interrupt-sensitive code in these routines.
I would think is usable (for example) for my 8MB ram laptop.
Anyone any thoughts on this?


Folkert van Heusden

[ http://www.vanheusden.com/Linux/kernel_patches.php3 ]
-
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/



willing to test ext3 fs

2001-04-17 Thread Heusden, Folkert van

Hi,

I have a dec alpha 300 with a scsi disk which is doing nothing 100% of
the time. Actually; nothing usefull, apart from the seti@home process :o)
I like to do a continues stress-test of the ext3 filesystem which aborts
when something fails. Am I helping anyone with that? In that case: what
application should I install to make it an usefull excercise?

mvg,
fvh.
-
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/



willing to test ext3 fs

2001-04-17 Thread Heusden, Folkert van

Hi,

I have a dec alpha 300 with a scsi disk which is doing nothing 100% of
the time. Actually; nothing usefull, apart from the seti@home process :o)
I like to do a continues stress-test of the ext3 filesystem which aborts
when something fails. Am I helping anyone with that? In that case: what
application should I install to make it an usefull excercise?

mvg,
fvh.
-
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/



RFC: pageable kernel-segments

2001-04-17 Thread Heusden, Folkert van

Would anyone be intrested (besides me) in a kernel which can page
out certain parts of itself? The kernel should be in some kind of
vmlinux-ish (as in: uncompressed) format on disk for on-demand
re-loading of pages which are discarded.
Certain parts of drivers could get the __pageable prefix or so
(like the __init parts of drivers which get removed) for letting
the paging-code know that it can be discared if memory-pressure
demands it.
__pageable -code would then be things like (e.g.!) the code which
handles the open()/close() of a device. Most of the time a device
spends more time doing read/write/ioctl then close/open so. Also;
hopefully there's no interrupt-sensitive code in these routines.
I would think is usable (for example) for my 8MB ram laptop.
Anyone any thoughts on this?


Folkert van Heusden

[ http://www.vanheusden.com/Linux/kernel_patches.php3 ]
-
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: Sources of entropy - /dev/random problem for network servers

2001-04-10 Thread Heusden, Folkert van

> AB> 2. Given that otherwise in at least my application (and machine
> AB> without keyboard and mouse can't be too uncommon) there is *no*
> AB> entropy otherwise, which is rather easier for a hacker. At least
> Put a soundcard in your system and install audio-entropyd.
> Works pretty nice.
I> Do you know where to find it? Freshmeat has a listing, but it's
I> pointing to mindrot.org and is 404 not found.

I still had the tgz-file. You can download the tarball from:
http://www.vanheusden.com/mirrors/

-
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] FW: proposal for systems that do not require security

2001-04-10 Thread Heusden, Folkert van

AP> Do you think it worth an effort ?

One could ask this question for all optimalisations.
In fact; for every project.

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



[RFC] FW: proposal for systems that do not require security

2001-04-10 Thread Heusden, Folkert van

Hi,

I have an idea: I have a couple of linux-systems running in a intranet which
is not connected to do outside world in any way. Since they're only used for
calculations for which there is no harm if anyone would tamper with them,
security is not neccessary. The only thing important, is performance. Huge
amounts of data must be transferred inbetween these boxes.
So, I was wondering: isn't it a nice idea to have a switch in the
configuration menu to disable entropy-gathering in the interrupt-routines,
have some simplistic routine (like x'=(x * m + a) % p) which returns a non-
cryptographic value, and something similar symplistic for the network-
traffic routines?

Thank you.


Folkert van Heusden
[ www.vanheusden.com ]
-
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/



[RFC] FW: proposal for systems that do not require security

2001-04-10 Thread Heusden, Folkert van

Hi,

I have an idea: I have a couple of linux-systems running in a intranet which
is not connected to do outside world in any way. Since they're only used for
calculations for which there is no harm if anyone would tamper with them,
security is not neccessary. The only thing important, is performance. Huge
amounts of data must be transferred inbetween these boxes.
So, I was wondering: isn't it a nice idea to have a switch in the
configuration menu to disable entropy-gathering in the interrupt-routines,
have some simplistic routine (like x'=(x * m + a) % p) which returns a non-
cryptographic value, and something similar symplistic for the network-
traffic routines?

Thank you.


Folkert van Heusden
[ www.vanheusden.com ]
-
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] FW: proposal for systems that do not require security

2001-04-10 Thread Heusden, Folkert van

AP Do you think it worth an effort ?

One could ask this question for all optimalisations.
In fact; for every project.

-
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: Sources of entropy - /dev/random problem for network servers

2001-04-10 Thread Heusden, Folkert van

 AB 2. Given that otherwise in at least my application (and machine
 AB without keyboard and mouse can't be too uncommon) there is *no*
 AB entropy otherwise, which is rather easier for a hacker. At least
 Put a soundcard in your system and install audio-entropyd.
 Works pretty nice.
I Do you know where to find it? Freshmeat has a listing, but it's
I pointing to mindrot.org and is 404 not found.

I still had the tgz-file. You can download the tarball from:
http://www.vanheusden.com/mirrors/

-
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: Sources of entropy - /dev/random problem for network servers

2001-04-09 Thread Heusden, Folkert van

>> However, only 3 drivers in drivers/net actually set
>> SA_SAMPLE_RANDOM when calling request_irq(). I believe
>> all of them should.
> No, because an attacker can potentially control input and make it
> non-random.
AB> 2. Given that otherwise in at least my application (and machine
AB> without keyboard and mouse can't be too uncommon) there is *no*
AB> entropy otherwise, which is rather easier for a hacker. At least

Put a soundcard in your system and install audio-entropyd.
Works pretty nice.
-
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: Sources of entropy - /dev/random problem for network servers

2001-04-09 Thread Heusden, Folkert van

 However, only 3 drivers in drivers/net actually set
 SA_SAMPLE_RANDOM when calling request_irq(). I believe
 all of them should.
 No, because an attacker can potentially control input and make it
 non-random.
AB 2. Given that otherwise in at least my application (and machine
AB without keyboard and mouse can't be too uncommon) there is *no*
AB entropy otherwise, which is rather easier for a hacker. At least

Put a soundcard in your system and install audio-entropyd.
Works pretty nice.
-
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: random PIDs

2001-04-05 Thread Heusden, Folkert van

>  Finished & tested my random PID kernel/fork.c:get_pid() replacement. 
> > This one keeps track of the last N (default is 64) pids who have exited.

> > These are then not used. So, one cannot have more then 32767 - (64 + 1 
> > (init) + 1 (idle)) = 32761 processes :o) 
> DW> Huh, should be 32701, right?! 
> You're absolutely right. It must've been the victory trance :o) 
M> Have you actually tried to create lots of threads?

No

M> IIRC get_pid will loop forever if it doesn't find a free pid, and in the
M> worst case you can trigger that with ~11000 running threads.

Ah, ok. But why would you have 11.000 running threads?

M> And the current code can create multiple threads with the same pid (I
M> never tried to trigger that bug, but it seems to be possible)

mine will do that too:

if (flags & CLONE_PID)
return current->pid;

As far as my knowledge reaches, threads are cloned which triggers the
code I quoted above.
-
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: random PIDs

2001-04-05 Thread Heusden, Folkert van

  Finished  tested my random PID kernel/fork.c:get_pid() replacement. 
  This one keeps track of the last N (default is 64) pids who have exited.

  These are then not used. So, one cannot have more then 32767 - (64 + 1 
  (init) + 1 (idle)) = 32761 processes :o) 
 DW Huh, should be 32701, right?! 
 You're absolutely right. It must've been the victory trance :o) 
M Have you actually tried to create lots of threads?

No

M IIRC get_pid will loop forever if it doesn't find a free pid, and in the
M worst case you can trigger that with ~11000 running threads.

Ah, ok. But why would you have 11.000 running threads?

M And the current code can create multiple threads with the same pid (I
M never tried to trigger that bug, but it seems to be possible)

mine will do that too:

if (flags  CLONE_PID)
return current-pid;

As far as my knowledge reaches, threads are cloned which triggers the
code I quoted above.
-
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: random PIDs

2001-04-04 Thread Heusden, Folkert van

> Finished & tested my random PID kernel/fork.c:get_pid() replacement.
> This one keeps track of the last N (default is 64) pids who have exited.
> These are then not used. So, one cannot have more then 32767 - (64 + 1
> (init) + 1 (idle)) = 32761 processes :o)
DW> Huh, should be 32701, right?!

You're absolutely right. It must've been the victory trance :o)
-
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/



random PIDs

2001-04-04 Thread Heusden, Folkert van

Finished & tested my random PID kernel/fork.c:get_pid() replacement.
This one keeps track of the last N (default is 64) pids who have exited.
These are then not used. So, one cannot have more then 32767 - (64 + 1
(init) + 1 (idle)) = 32761 processes :o)

I know that it was all implemented before, but this patch is very small 
and I couldn't stand the idea the fact that my last announcement was for
a patch which didn't work at all :o)

One can find it at: http://www.vanheusden.com/Linux/kernel_patches.php3
(or: http://www.vanheusden.com/Linux/fp-2.2.19.patch.gz but then you
miss the list of other patches ;-])
Patch is against kernel 2.2.19.

I did not do any performance tests, but the machine I tested it on
(300MHz dec alpha) felt (felt?) as smooth as before :o)


Folkert van Heusden

[ www.vanheusden.com ]

p.s. the patch mentioned above also raises the number of pool-words
from 128 to 2048, adds code to do_exit which tells you if the idle
task is killed (as in 2.4.x), and replaces
net/core/utils.c:net_[s]random() with something which uses
get_random_bytes().
-
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/



random PIDs

2001-04-04 Thread Heusden, Folkert van

Finished  tested my random PID kernel/fork.c:get_pid() replacement.
This one keeps track of the last N (default is 64) pids who have exited.
These are then not used. So, one cannot have more then 32767 - (64 + 1
(init) + 1 (idle)) = 32761 processes :o)

I know that it was all implemented before, but this patch is very small 
and I couldn't stand the idea the fact that my last announcement was for
a patch which didn't work at all :o)

One can find it at: http://www.vanheusden.com/Linux/kernel_patches.php3
(or: http://www.vanheusden.com/Linux/fp-2.2.19.patch.gz but then you
miss the list of other patches ;-])
Patch is against kernel 2.2.19.

I did not do any performance tests, but the machine I tested it on
(300MHz dec alpha) felt (felt?) as smooth as before :o)


Folkert van Heusden

[ www.vanheusden.com ]

p.s. the patch mentioned above also raises the number of pool-words
from 128 to 2048, adds code to do_exit which tells you if the idle
task is killed (as in 2.4.x), and replaces
net/core/utils.c:net_[s]random() with something which uses
get_random_bytes().
-
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: random PIDs

2001-04-04 Thread Heusden, Folkert van

 Finished  tested my random PID kernel/fork.c:get_pid() replacement.
 This one keeps track of the last N (default is 64) pids who have exited.
 These are then not used. So, one cannot have more then 32767 - (64 + 1
 (init) + 1 (idle)) = 32761 processes :o)
DW Huh, should be 32701, right?!

You're absolutely right. It must've been the victory trance :o)
-
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/



unresolved symbols; I must have lost my brain

2001-04-03 Thread Heusden, Folkert van

People,

Somehow I must have lost my brain.
In exit.c I introduced some array:

pid_t pidarray[100];

in fork.c I refer to this array:

extern pid_t pidarray[100];

(or something like that. looked it up in K, couldn't
find what I did wrong)

for some reason the kernel build process complains
about the pidarray it could not find.
This is a very trivial problem, but, well, I'm not
seing it. Tried to move the declaration to some
header-file, etc. etc. Done it all, doesn't work.

Anyone who can shed some light on this problem?
-
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/



unresolved symbols; I must have lost my brain

2001-04-03 Thread Heusden, Folkert van

People,

Somehow I must have lost my brain.
In exit.c I introduced some array:

pid_t pidarray[100];

in fork.c I refer to this array:

extern pid_t pidarray[100];

(or something like that. looked it up in KR, couldn't
find what I did wrong)

for some reason the kernel build process complains
about the pidarray it could not find.
This is a very trivial problem, but, well, I'm not
seing it. Tried to move the declaration to some
header-file, etc. etc. Done it all, doesn't work.

Anyone who can shed some light on this problem?
-
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/



[PATCH] kernel/exit.c - 2.4.2 - small optimalisation (very small) to do_exit()

2001-03-26 Thread Heusden, Folkert van

Hi,

This very small patches re-orders 2 if-statements so that in the
most common case 1 less if-statement is executed, in the worst
case the same number of if-statements is executed (doesn't matter
though: it's would be the fault-situation anyway).

diff -ur --minimal linux-vanilla/kernel/exit.c linux-2.4.2/kernel/exit.c
--- linux-vanilla/kernel/exit.c Mon Mar 26 09:28:13 2001
+++ linux-2.4.2/kernel/exit.c   Mon Mar 26 10:50:30 2001
@@ -425,10 +425,12 @@
 
if (in_interrupt())
panic("Aiee, killing interrupt handler!");
-   if (!tsk->pid)
-   panic("Attempted to kill the idle task!");
-   if (tsk->pid == 1)
-   panic("Attempted to kill init!");
+   if (tsk->pid <= 1) {
+   if (tsk->pid)
+   panic("Attempted to kill init!");
+   else
+   panic("Attempted to kill the idle task!");
+   }
tsk->flags |= PF_EXITING;
del_timer_sync(>real_timer);


Greetings,

Folkert van Heusden ([EMAIL PROTECTED])
[ www.vanheusden.com ]

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



[PATCH] kernel/exit.c - 2.4.2 - small optimalisation (very small) to do_exit()

2001-03-26 Thread Heusden, Folkert van

Hi,

This very small patches re-orders 2 if-statements so that in the
most common case 1 less if-statement is executed, in the worst
case the same number of if-statements is executed (doesn't matter
though: it's would be the fault-situation anyway).

diff -ur --minimal linux-vanilla/kernel/exit.c linux-2.4.2/kernel/exit.c
--- linux-vanilla/kernel/exit.c Mon Mar 26 09:28:13 2001
+++ linux-2.4.2/kernel/exit.c   Mon Mar 26 10:50:30 2001
@@ -425,10 +425,12 @@
 
if (in_interrupt())
panic("Aiee, killing interrupt handler!");
-   if (!tsk-pid)
-   panic("Attempted to kill the idle task!");
-   if (tsk-pid == 1)
-   panic("Attempted to kill init!");
+   if (tsk-pid = 1) {
+   if (tsk-pid)
+   panic("Attempted to kill init!");
+   else
+   panic("Attempted to kill the idle task!");
+   }
tsk-flags |= PF_EXITING;
del_timer_sync(tsk-real_timer);


Greetings,

Folkert van Heusden ([EMAIL PROTECTED])
[ www.vanheusden.com ]

-
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] Prevent OOM from killing init

2001-03-23 Thread Heusden, Folkert van

> That's not the OOM killer however, but init dying because it
> couldn't get the memory it needed to satisfy a page fault or
> somesuch...

Ehrm, I would like to re-state that it still would be nice if
some mechanism got introduced which enables one to set certain
processes to "cannot be killed".
For example: I would hate it it the UPS monitoring daemon got
killed for obvious reasons :o)
-
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] Prevent OOM from killing init

2001-03-23 Thread Heusden, Folkert van

 That's not the OOM killer however, but init dying because it
 couldn't get the memory it needed to satisfy a page fault or
 somesuch...

Ehrm, I would like to re-state that it still would be nice if
some mechanism got introduced which enables one to set certain
processes to "cannot be killed".
For example: I would hate it it the UPS monitoring daemon got
killed for obvious reasons :o)
-
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] Prevent OOM from killing init

2001-03-22 Thread Heusden, Folkert van

> Since the system will panic if the init process is chosen by
> the OOM killer, the following patch prevents select_bad_process()
> from picking init.

Hmmm, wouldn't it be nice to make this all configurable? Like; have
some list of PIDs that can be killed?
I would hate it the daemon that checks my UPS would get killed...
(that deamon brings the machine down safely when the UPS'
batteries get emptied).
Would be something like:

int *dont_kill_pid, ndont_kill_pid;
// initialize with at least pid '1' and n=1

 for_each_task(p) {
int loop;
for(loop=ndont_kill_pid-1; loop>=0; loop--)
{
if (dont_kill_pid[loop] == p->pid) break;
}
  if (p->pid && !(loop>=0)) {
 int points = badness(p);
 if (points > maxpoints) {
 chosen = p;


(untested (not even compiled or anything) code)
-
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: mysterious card

2001-03-22 Thread Heusden, Folkert van

> Ok, the question is: does anyone know a place on the web where I can find
> specifications of ISA-slots? I need to know what is supposed to be
connected
> to
> the pins (1, 2, 6, etc.)
AO> It is supposed to do that!

Yes, I guess so!

AO> That sounds like the card that came with an old DOS debugger.

Not really. I found it in some high-end UNIX server (non-Linux).

AO> The old 8088 PCs did not have a reset switch. This was so you could do
AO> hardware breaks when the whole system was locked up.

This one triggers the I/O Channel Check pin (pin 1 (at the frame), component
side).
-
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: mysterious card

2001-03-22 Thread Heusden, Folkert van

 Ok, the question is: does anyone know a place on the web where I can find
 specifications of ISA-slots? I need to know what is supposed to be
connected
 to
 the pins (1, 2, 6, etc.)
AO It is supposed to do that!

Yes, I guess so!

AO That sounds like the card that came with an old DOS debugger.

Not really. I found it in some high-end UNIX server (non-Linux).

AO The old 8088 PCs did not have a reset switch. This was so you could do
AO hardware breaks when the whole system was locked up.

This one triggers the I/O Channel Check pin (pin 1 (at the frame), component
side).
-
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/



mysterious card

2001-03-21 Thread Heusden, Folkert van

Hi,

I have this mysterious 8 bit ISA card with nothing more then 2 smb-mounted
ic's
and a button. It seems to be something that should force a system memory
dump.
I think I can handle the code-writing, but since there's no documentation I
have
to find out how things are working.
Ok, the question is: does anyone know a place on the web where I can find
specifications of ISA-slots? I need to know what is supposed to be connected
to
the pins (1, 2, 6, etc.)


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



mysterious card

2001-03-21 Thread Heusden, Folkert van

Hi,

I have this mysterious 8 bit ISA card with nothing more then 2 smb-mounted
ic's
and a button. It seems to be something that should force a system memory
dump.
I think I can handle the code-writing, but since there's no documentation I
have
to find out how things are working.
Ok, the question is: does anyone know a place on the web where I can find
specifications of ISA-slots? I need to know what is supposed to be connected
to
the pins (1, 2, 6, etc.)


-
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: Per user private directories - trfs

2001-03-19 Thread Heusden, Folkert van

> Translators for providing per user private directories and restricting
> visibility of files and directories using the translation filesystem are
> available now at
> http://trfs.sourceforge.net/
> Per user private directories:
> Files created in a per user private directory are not visible to users
> other than the owner of the files.

I like the concept, I would have done it different though: I would look
at the bits and see if a user can do anything with a file. Can
he/she (from now on I'll write 'xe' for that) read or write or execute a
file (or is owner of course)? -> file is visible. Xe is in group of file?
And Xe can r/w/x file? -> visible. all other cases: invisible.

-
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: Per user private directories - trfs

2001-03-19 Thread Heusden, Folkert van

 Translators for providing per user private directories and restricting
 visibility of files and directories using the translation filesystem are
 available now at
 http://trfs.sourceforge.net/
 Per user private directories:
 Files created in a per user private directory are not visible to users
 other than the owner of the files.

I like the concept, I would have done it different though: I would look
at the bits and see if a user can do anything with a file. Can
he/she (from now on I'll write 'xe' for that) read or write or execute a
file (or is owner of course)? - file is visible. Xe is in group of file?
And Xe can r/w/x file? - visible. all other cases: invisible.

-
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 is unstable

2001-03-01 Thread Heusden, Folkert van

> memory area has to be accessed. In some memory management systems,
> the allocated area has to be actually written (demand zero paging).
> If you execute from a user account, not root, with ulimits enabled,
> you should be able to do:
> char *p;
>   for(;;)
>  {
> if((p = (char *) malloc(WHATEVER)) == NULL)
> {
>  puts("Out of memory");
>  exit(1);
> }
> *p = (char) 0x01;/* Write to memory */
> }
>   ... without hanging the system.

Allow me to nitpick :o)
int loop;
for(loop=0;loophttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



RE: Kernel is unstable

2001-03-01 Thread Heusden, Folkert van

 memory area has to be accessed. In some memory management systems,
 the allocated area has to be actually written (demand zero paging).
 If you execute from a user account, not root, with ulimits enabled,
 you should be able to do:
 char *p;
   for(;;)
  {
 if((p = (char *) malloc(WHATEVER)) == NULL)
 {
  puts("Out of memory");
  exit(1);
 }
 *p = (char) 0x01;/* Write to memory */
 }
   ... without hanging the system.

Allow me to nitpick :o)
int loop;
for(loop=0;loopWHATEVER; loop+=PAGESIZE)
p[loop] = 0x01;

Because: as far as I remember only the pages that are touched are
allocated, not the whole memory-block.

But, indead, that's nitpicking. Sorry for that :o)
-
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: binfmt_script and ^M

2001-02-27 Thread Heusden, Folkert van

> > When running a script (perl in this case) that has DOS-style newlines
> > (\r\n), Linux 2.4.2 can't find an interpreter because it doesn't
> > recognize the \r.  The following patch should fix this (untested).
> _should_ it work with the \r in it?
IV> IMHO, yes.  This set of files were created on Windows, then zipped and
IV> uploaded to a Linux server, unpacked.  This does not change the \r.

But; it's not that much of hassle to run it trough some awk/sed/whatsoever
script, would it? Imho there should be as less as possible code in the
kernel which could've also been done in user-space.

> + if (cp - 1 == '\r') <--- *)
> There might be a problem with your patch: at the '*)': if the '\n' is the
> first character on the line, the cp-1 (which should be *(cp-1) I think)
IV> You're right there.

Phew, then I have at least 1 thing right in my message since I was wrong
with:

> would point before the buffer which can be un-allocated memory.

If only I had read the code myself :o)

IV> No, the first two characters are always `#!'.

Yes, absolutely right.
-
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: binfmt_script and ^M

2001-02-27 Thread Heusden, Folkert van

> When running a script (perl in this case) that has DOS-style newlines
> (\r\n), Linux 2.4.2 can't find an interpreter because it doesn't
> recognize the \r.  The following patch should fix this (untested).

_should_ it work with the \r in it?

There might be a problem with your patch: at the '*)': if the '\n' is the
first character on the line, the cp-1 (which should be *(cp-1) I think)
would point before the buffer which can be un-allocated memory.



--- binfmt_script.c~Mon Feb 26 17:42:09 2001
+++ binfmt_script.c Tue Feb 27 13:39:47 2001
@@ -36,6 +36,8 @@
bprm->buf[BINPRM_BUF_SIZE - 1] = '\0';
if ((cp = strchr(bprm->buf, '\n')) == NULL)
cp = bprm->buf+BINPRM_BUF_SIZE-1;
+   if (cp - 1 == '\r') <--- *)
+ cp--;
*cp = '\0';
while (cp > bprm->buf) {
cp--;


Greetings,
Folkert van Heusden
[ www.vanheusden.com ]
-
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: random PID generation

2001-02-27 Thread Heusden, Folkert van

> I have already written a 2.2 implementation which does not suffer from
these 
> problems.

Yes, someone pointed me at it. To be honest (and with all due respect): I
found
it to be a bit over-complicated. Like; in my opinion it's only usefull to
have
absolute random chosen PIDs, or not. Not all those options are needed in my
opinion.

> It was rejected because Alan Cox (and others) felt it only provided 
> security through obscurity. 

Yeah, well, yeah. My patch wasn't actually ment to be included in the main-
kernel. I agree with the security-by-obscurity argument altough I think it's
_not ALWAYS_ a bad thing.
What I am trying to say is: I agree that sofware should be written so that
they can't be exploited in one way or another. But since software is written
by humans, it's likely that bugs stay always in. Furthermore; it's always
possible that in the future new exploits are invented which exploit things
the original programmer didn't think of, and also; new libcs might have
security-problems which affect your software. To prevent that your system
gets cracked by some script-kiddie, I found it a good thing to patch the
mainstream-kernel with patches that disable executable stacks, make the
/proc filesystem more restricted, etc. etc. And in my quest for creating a
secure-as-possible system which anticipates on future exploits I found that
using random PIDs is a good thing.
I hope I made myself clear; english is not my native language which makes
this a rather big chalenge.


Greetings,
Folkert van Heusden
[ www.vanheusden.com ]
-
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: random PID generation

2001-02-27 Thread Heusden, Folkert van

 I have already written a 2.2 implementation which does not suffer from
these 
 problems.

Yes, someone pointed me at it. To be honest (and with all due respect): I
found
it to be a bit over-complicated. Like; in my opinion it's only usefull to
have
absolute random chosen PIDs, or not. Not all those options are needed in my
opinion.

 It was rejected because Alan Cox (and others) felt it only provided 
 security through obscurity. 

Yeah, well, yeah. My patch wasn't actually ment to be included in the main-
kernel. I agree with the security-by-obscurity argument altough I think it's
_not ALWAYS_ a bad thing.
What I am trying to say is: I agree that sofware should be written so that
they can't be exploited in one way or another. But since software is written
by humans, it's likely that bugs stay always in. Furthermore; it's always
possible that in the future new exploits are invented which exploit things
the original programmer didn't think of, and also; new libcs might have
security-problems which affect your software. To prevent that your system
gets cracked by some script-kiddie, I found it a good thing to patch the
mainstream-kernel with patches that disable executable stacks, make the
/proc filesystem more restricted, etc. etc. And in my quest for creating a
secure-as-possible system which anticipates on future exploits I found that
using random PIDs is a good thing.
I hope I made myself clear; english is not my native language which makes
this a rather big chalenge.


Greetings,
Folkert van Heusden
[ www.vanheusden.com ]
-
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: binfmt_script and ^M

2001-02-27 Thread Heusden, Folkert van

 When running a script (perl in this case) that has DOS-style newlines
 (\r\n), Linux 2.4.2 can't find an interpreter because it doesn't
 recognize the \r.  The following patch should fix this (untested).

_should_ it work with the \r in it?

There might be a problem with your patch: at the '*)': if the '\n' is the
first character on the line, the cp-1 (which should be *(cp-1) I think)
would point before the buffer which can be un-allocated memory.



--- binfmt_script.c~Mon Feb 26 17:42:09 2001
+++ binfmt_script.c Tue Feb 27 13:39:47 2001
@@ -36,6 +36,8 @@
bprm-buf[BINPRM_BUF_SIZE - 1] = '\0';
if ((cp = strchr(bprm-buf, '\n')) == NULL)
cp = bprm-buf+BINPRM_BUF_SIZE-1;
+   if (cp - 1 == '\r') --- *)
+ cp--;
*cp = '\0';
while (cp  bprm-buf) {
cp--;


Greetings,
Folkert van Heusden
[ www.vanheusden.com ]
-
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: binfmt_script and ^M

2001-02-27 Thread Heusden, Folkert van

  When running a script (perl in this case) that has DOS-style newlines
  (\r\n), Linux 2.4.2 can't find an interpreter because it doesn't
  recognize the \r.  The following patch should fix this (untested).
 _should_ it work with the \r in it?
IV IMHO, yes.  This set of files were created on Windows, then zipped and
IV uploaded to a Linux server, unpacked.  This does not change the \r.

But; it's not that much of hassle to run it trough some awk/sed/whatsoever
script, would it? Imho there should be as less as possible code in the
kernel which could've also been done in user-space.

 + if (cp - 1 == '\r') --- *)
 There might be a problem with your patch: at the '*)': if the '\n' is the
 first character on the line, the cp-1 (which should be *(cp-1) I think)
IV You're right there.

Phew, then I have at least 1 thing right in my message since I was wrong
with:

 would point before the buffer which can be un-allocated memory.

If only I had read the code myself :o)

IV No, the first two characters are always `#!'.

Yes, absolutely right.
-
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/



awe_ram.c

2001-02-26 Thread Heusden, Folkert van

Hi,

On http://helllabs.org/~claudio/awebd/awe_ram.c I found some code which
transforms the
RAM on an AWE32/64 into a block-device. I tried to compile it, but I did not
succeed.
The writer of this code doesn't respond to e-mails.
Anyone out there who has a clue what is going wrong with it? (using kernel
2.2.18)

Am getting the following errors:
bash-2.03# gcc -Wall -Wstrict-prototypes -Winline -O2 -fomit-frame-pointer
-I/usr/src/linux/include/ -c awe_ram.c -o awe_ram.o 2>&1 | more 
In file included from /usr/src/linux/include/linux/sched.h:74,
 from awe_ram.c:26:
/usr/src/linux/include/asm/processor.h:287: warning: `struct task_struct'
declared inside parameter list
/usr/src/linux/include/asm/processor.h:287: warning: its scope is only this
definition or declaration,
/usr/src/linux/include/asm/processor.h:287: warning: which is probably not
what you want.
/usr/src/linux/include/asm/processor.h:291: warning: `struct task_struct'
declared inside parameter list
In file included from /usr/src/linux/include/linux/blk.h:4,
 from awe_ram.c:42:
/usr/src/linux/include/linux/blkdev.h:23: parse error before `kdev_t'
/usr/src/linux/include/linux/blkdev.h:23: warning: no semicolon at end of
struct or union
/usr/src/linux/include/linux/blkdev.h:36: parse error before `}'
/usr/src/linux/include/linux/blkdev.h:39: parse error before `dev'
/usr/src/linux/include/linux/blkdev.h:39: warning: function declaration
isn't a prototype
/usr/src/linux/include/linux/blkdev.h:55: parse error before `unsigned'
/usr/src/linux/include/linux/blkdev.h:55: warning: function declaration
isn't a prototype
/usr/src/linux/include/linux/blkdev.h:75: field `plug' has incomplete type
/usr/src/linux/include/linux/blkdev.h:94: parse error before `kdev_t'
/usr/src/linux/include/linux/blkdev.h:94: warning: function declaration
isn't a prototype
/usr/src/linux/include/linux/blkdev.h:96: parse error before `mddev'
/usr/src/linux/include/linux/blkdev.h:96: warning: function declaration
isn't a prototype



Greetings,
Folkert van Heusden.
-
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: random PID generation

2001-02-23 Thread Heusden, Folkert van

>> My code runs trough the whole task_list to see if a chosen pid is already

>> in use or not. 
> But it doesn't check for a recently used PID. Lets say your system is 
> exhausting 1000 PIDs/second, and that there is a window of 20ms between
you 
> determining which PID to send to, and the recipient process receiving it. 

Ah, I get your point. Good point :o)

I was thinking: I could split the PIDs up in 2...16383 and 16384-32767 and
then
switch between them when a process ends? nah, that doesn't help it.
hmmm.
I think random increments (instead of last_pid+1) would be the best thing to
do then?


-
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: random PID generation

2001-02-23 Thread Heusden, Folkert van

>> I wrote a patch against 2.2.18 and 2.4.1 to have the kernel generate 
>> random PIDs. You can find it at http://vanheusden.com/Linux/security.php3

>> (amongst other patches). Beware: pretty much experimental and likely to 
>> make your linux-pc perform like a win95 platform. 
> Well - I'm not sure that this is a good idea. When PIDs increase 
> monotonically, chances are very small that the race condition implicit in 
> sending any signal to a process results in killing the wrong process (ie,
a 
> new process, but with the same PID) - you'd need to zoom through 32000
PIDs 
> in a very short time to make this happen. 
> With truly random PIDs, there is a much larger chance of a new process 
> sitting on a recently used PID. 

My code runs trough the whole task_list to see if a chosen pid is already
in use or not.

> What would work is to have cryptographically randomly generated PIDs which

> would then guarantee not to return a previously returned number within
32000 
> tries, and also not be predictable - there must be algoritms out there
which 
> do this. 

That's also an option!
But for simplicity-sake, I used the get_random_bytes() function (from
the /dev/random-device) combined with a loop. It's a simplistic hack, but
it'll work for my paranoia mind :o)


Greetings,

Folkert van Heusden
-
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: random PID generation

2001-02-23 Thread Heusden, Folkert van

 I wrote a patch against 2.2.18 and 2.4.1 to have the kernel generate 
 random PIDs. You can find it at http://vanheusden.com/Linux/security.php3

 (amongst other patches). Beware: pretty much experimental and likely to 
 make your linux-pc perform like a win95 platform. 
 Well - I'm not sure that this is a good idea. When PIDs increase 
 monotonically, chances are very small that the race condition implicit in 
 sending any signal to a process results in killing the wrong process (ie,
a 
 new process, but with the same PID) - you'd need to zoom through 32000
PIDs 
 in a very short time to make this happen. 
 With truly random PIDs, there is a much larger chance of a new process 
 sitting on a recently used PID. 

My code runs trough the whole task_list to see if a chosen pid is already
in use or not.

 What would work is to have cryptographically randomly generated PIDs which

 would then guarantee not to return a previously returned number within
32000 
 tries, and also not be predictable - there must be algoritms out there
which 
 do this. 

That's also an option!
But for simplicity-sake, I used the get_random_bytes() function (from
the /dev/random-device) combined with a loop. It's a simplistic hack, but
it'll work for my paranoia mind :o)


Greetings,

Folkert van Heusden
-
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: random PID generation

2001-02-23 Thread Heusden, Folkert van

 My code runs trough the whole task_list to see if a chosen pid is already

 in use or not. 
 But it doesn't check for a recently used PID. Lets say your system is 
 exhausting 1000 PIDs/second, and that there is a window of 20ms between
you 
 determining which PID to send to, and the recipient process receiving it. 

Ah, I get your point. Good point :o)

I was thinking: I could split the PIDs up in 2...16383 and 16384-32767 and
then
switch between them when a process ends? nah, that doesn't help it.
hmmm.
I think random increments (instead of last_pid+1) would be the best thing to
do then?


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



random PID generation

2001-02-22 Thread Heusden, Folkert van

Hi,

I wrote a patch against 2.2.18 and 2.4.1 to have the kernel generate random
PIDs.
You can find it at http://vanheusden.com/Linux/security.php3 (amongst other
patches).
Beware: pretty much experimental and likely to make your linux-pc perform
like a
win95 platform.


Greetings,

Folkert van Heusden
-
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/



random PID generation

2001-02-22 Thread Heusden, Folkert van

Hi,

I wrote a patch against 2.2.18 and 2.4.1 to have the kernel generate random
PIDs.
You can find it at http://vanheusden.com/Linux/security.php3 (amongst other
patches).
Beware: pretty much experimental and likely to make your linux-pc perform
like a
win95 platform.


Greetings,

Folkert van Heusden
-
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: i82808 hardware hub RNG

2000-11-05 Thread Heusden, Folkert van

> Excellent!
> Got any URLs?
RML> its been in 2.4 for a year or so, although only in the last few tests
as
RML> it supported i815. it has been in 2.2 since 2.2.17 or the current
2.2.18.

2.2.18 I think, or some undetected disk-error must have swept it away from
the local sourcetree :o)

RML> take a look at linux/drivers/char/i810_rng.c
RML> Jeff's homepage for it is http://gtf.org/garzik/drivers/i810_rng/ but
RML> probably not as up to date as the C source.

Thank you!

RML> it works great for me. i have it feeding the standard entropy pool, so
my
RML> /dev/random is fat with entropy.

You didn't forget to change the line
random.c: #define POOLWORDS 128/* Power of 2 - note that this is 32-bit
words */
to
#define POOLWORDS 2048/* Power of 2 - note that this is 32-bit words */
? :o)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



RE: i82808 hardware hub RNG

2000-11-05 Thread Heusden, Folkert van

> I wrote a daemon that fetches (as root-user) random numbers from the RNG
in
> the i82808 (found on 815-chipsets).
> You can download it from http://www.vanheusden.com/Linux/random.php3 .
> Currently, I'm trying to rewrite things into a kernel-module so that one
has
> a standard character device which can deliver random values then.
> Please give it a try as I do not own a PC with such a motherboard ;-/
PR> So how is this different from drivers/char/i810_rng.c ?

I don't know; 2.2.17 doesn't have it :-}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



RE: i82808 hardware hub RNG

2000-11-05 Thread Heusden, Folkert van

> I wrote a daemon that fetches (as root-user) random numbers from the RNG
in
> the i82808 (found on 815-chipsets).
> You can download it from http://www.vanheusden.com/Linux/random.php3 .
> Currently, I'm trying to rewrite things into a kernel-module so that one
has
> a standard character device which can deliver random values then.
> Please give it a try as I do not own a PC with such a motherboard ;-/
RML> a driver for this already exists in 2.4 and was recently back-ported to
RML> 2.2. it works on i810, i815, and i820. it features a char device for
RML> grabbing entropy and a timer device to inject the entropy directly into
RML> /dev/random.
RML> Jeff Garzik wrote it.

Excellent!
Got any URLs?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



i82808 hardware hub RNG

2000-11-05 Thread Heusden, Folkert van

Hi,

I wrote a daemon that fetches (as root-user) random numbers from the RNG in
the i82808 (found on 815-chipsets).
You can download it from http://www.vanheusden.com/Linux/random.php3 .
Currently, I'm trying to rewrite things into a kernel-module so that one has
a standard character device which can deliver random values then.
Please give it a try as I do not own a PC with such a motherboard ;-/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



i82808 hardware hub RNG

2000-11-05 Thread Heusden, Folkert van

Hi,

I wrote a daemon that fetches (as root-user) random numbers from the RNG in
the i82808 (found on 815-chipsets).
You can download it from http://www.vanheusden.com/Linux/random.php3 .
Currently, I'm trying to rewrite things into a kernel-module so that one has
a standard character device which can deliver random values then.
Please give it a try as I do not own a PC with such a motherboard ;-/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



RE: i82808 hardware hub RNG

2000-11-05 Thread Heusden, Folkert van

 I wrote a daemon that fetches (as root-user) random numbers from the RNG
in
 the i82808 (found on 815-chipsets).
 You can download it from http://www.vanheusden.com/Linux/random.php3 .
 Currently, I'm trying to rewrite things into a kernel-module so that one
has
 a standard character device which can deliver random values then.
 Please give it a try as I do not own a PC with such a motherboard ;-/
RML a driver for this already exists in 2.4 and was recently back-ported to
RML 2.2. it works on i810, i815, and i820. it features a char device for
RML grabbing entropy and a timer device to inject the entropy directly into
RML /dev/random.
RML Jeff Garzik wrote it.

Excellent!
Got any URLs?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



RE: i82808 hardware hub RNG

2000-11-05 Thread Heusden, Folkert van

 I wrote a daemon that fetches (as root-user) random numbers from the RNG
in
 the i82808 (found on 815-chipsets).
 You can download it from http://www.vanheusden.com/Linux/random.php3 .
 Currently, I'm trying to rewrite things into a kernel-module so that one
has
 a standard character device which can deliver random values then.
 Please give it a try as I do not own a PC with such a motherboard ;-/
PR So how is this different from drivers/char/i810_rng.c ?

I don't know; 2.2.17 doesn't have it :-}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



RE: i82808 hardware hub RNG

2000-11-05 Thread Heusden, Folkert van

 Excellent!
 Got any URLs?
RML its been in 2.4 for a year or so, although only in the last few tests
as
RML it supported i815. it has been in 2.2 since 2.2.17 or the current
2.2.18.

2.2.18 I think, or some undetected disk-error must have swept it away from
the local sourcetree :o)

RML take a look at linux/drivers/char/i810_rng.c
RML Jeff's homepage for it is http://gtf.org/garzik/drivers/i810_rng/ but
RML probably not as up to date as the C source.

Thank you!

RML it works great for me. i have it feeding the standard entropy pool, so
my
RML /dev/random is fat with entropy.

You didn't forget to change the line
random.c: #define POOLWORDS 128/* Power of 2 - note that this is 32-bit
words */
to
#define POOLWORDS 2048/* Power of 2 - note that this is 32-bit words */
? :o)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



how do I access memory-mapped hardware from userspace?

2000-11-01 Thread Heusden, Folkert van

Forgoto my previous question (threading in kernel); got an other question:
how do I access memory-mapped hardware from userspace?

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



fork in module?

2000-11-01 Thread Heusden, Folkert van

what would be the way of starting a sub-process in a module which then would
run in the background? I guess plain fork() won't work?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



fork in module?

2000-11-01 Thread Heusden, Folkert van

what would be the way of starting a sub-process in a module which then would
run in the background? I guess plain fork() won't work?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



how do I access memory-mapped hardware from userspace?

2000-11-01 Thread Heusden, Folkert van

Forgoto my previous question (threading in kernel); got an other question:
how do I access memory-mapped hardware from userspace?

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



2.2.16 & memory usage

2000-10-31 Thread Heusden, Folkert van

Is an 2.2.16 system that suddenly out of the blue (always! like; every time
the system is started) uses all memory and all swap-space and then crashes
of any intrest?
Or should I just ignore it and install 2.2.17?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



2.2.16 memory usage

2000-10-31 Thread Heusden, Folkert van

Is an 2.2.16 system that suddenly out of the blue (always! like; every time
the system is started) uses all memory and all swap-space and then crashes
of any intrest?
Or should I just ignore it and install 2.2.17?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



RE: getting include-files from arch//subdir

2000-10-24 Thread Heusden, Folkert van

Hi,

ADC> why not 
ADC> #include 
ADC> Amit

Since that is not cross-platform. I like a solution which does the #include
transparantly
for alpha/i386/etc.


"Heusden, Folkert van" wrote:
> 
> I need to include (in a driver) a header-file from arch//subdir. I
> could, of course,
> do something like #include "../../arch/i386/{etc}" with a couple of
#ifdef's
> to get things
> working for each environment. I guess that's now the way to do it cleanly.
> What would be _the_ way to do it?
> 
> Thanks.
> 
> Folkert van Heusden.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> 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]
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]
Please read the FAQ at http://www.tux.org/lkml/



RE: getting include-files from arch/arch/subdir

2000-10-24 Thread Heusden, Folkert van

Hi,

ADC why not 
ADC #include arch/i386/etc.h
ADC Amit

Since that is not cross-platform. I like a solution which does the #include
transparantly
for alpha/i386/etc.


"Heusden, Folkert van" wrote:
 
 I need to include (in a driver) a header-file from arch/arch/subdir. I
 could, of course,
 do something like #include "../../arch/i386/{etc}" with a couple of
#ifdef's
 to get things
 working for each environment. I guess that's now the way to do it cleanly.
 What would be _the_ way to do it?
 
 Thanks.
 
 Folkert van Heusden.
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 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]
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]
Please read the FAQ at http://www.tux.org/lkml/



getting include-files from arch//subdir

2000-10-23 Thread Heusden, Folkert van

I need to include (in a driver) a header-file from arch//subdir. I
could, of course,
do something like #include "../../arch/i386/{etc}" with a couple of #ifdef's
to get things
working for each environment. I guess that's now the way to do it cleanly.
What would be _the_ way to do it?

Thanks.

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



getting include-files from arch/arch/subdir

2000-10-23 Thread Heusden, Folkert van

I need to include (in a driver) a header-file from arch/arch/subdir. I
could, of course,
do something like #include "../../arch/i386/{etc}" with a couple of #ifdef's
to get things
working for each environment. I guess that's now the way to do it cleanly.
What would be _the_ way to do it?

Thanks.

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



RE: 2.2.17 dead after "Now booting the kernel"-message (586)

2000-09-12 Thread Heusden, Folkert van

> Yesterday I tried to install 2.2.17 on a pentium-mmx. Nothing fancy;
3c509,
[snip]
> What should I do as the next problem-determinationstep?
YOU> Check if you didn't accidentally build a Pentium Pro/II kernel
YOU> (see the .config file, or with "make menuconfig" / "make xconfig")

That was one of the first things I checked :-)
No, I had that one correct.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



2.2.17 dead after "Now booting the kernel"-message (586)

2000-09-12 Thread Heusden, Folkert van

Hi,

Yesterday I tried to install 2.2.17 on a pentium-mmx. Nothing fancy; 3c509,
3c905B, ide disk+cdrom, 32MB ram.
2.0.38 runs fine.
system crashes (hangs) after it decompressed the kernel, after the "Now
booting the kernel"-message.
I tried both an bzImage and the zImage.

Couldn't find anything in the FAQ on this.

What should I do as the next problem-determinationstep?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



2.2.17 dead after Now booting the kernel-message (586)

2000-09-12 Thread Heusden, Folkert van

Hi,

Yesterday I tried to install 2.2.17 on a pentium-mmx. Nothing fancy; 3c509,
3c905B, ide disk+cdrom, 32MB ram.
2.0.38 runs fine.
system crashes (hangs) after it decompressed the kernel, after the "Now
booting the kernel"-message.
I tried both an bzImage and the zImage.

Couldn't find anything in the FAQ on this.

What should I do as the next problem-determinationstep?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/