RE: Cosmetic JFFS patch.
> 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.
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
[...] >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
[...] 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
>> 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
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
> 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
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
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
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
(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
(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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
>> 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
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
> 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
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
> 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
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
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
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
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
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()
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()
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
> 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
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
> 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
> 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
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
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
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
> 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
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
> 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
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
> > 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
> 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
> 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
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
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
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
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
>> 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
>> 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
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
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
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
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
> 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
> 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
> 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
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
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
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
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
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?
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?
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?
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?
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
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
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
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
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
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
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)
> 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)
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)
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/
