Re: A question

2000-06-20 Thread Dries van Oosten
On Tue, 20 Jun 2000, Alan Cox wrote: hybrid crossing between the V7 and the linux method. Like allocating a relatively small struct, but then make it an option to grow the struct by making a linked list of these structs. Given the low computative power of The struct size is fixed - I

Re: A question

2000-06-20 Thread Larry Howard Mittman
Alan Cox wrote: > hybrid crossing between the V7 and the linux method. Like allocating a > relatively small struct, but then make it an option to grow the struct by > making a linked list of these structs. Given the low computative power of The struct size is fixed - I dont follow you If I

Re: A question

2000-06-20 Thread Alan Cox
From what I understand, using the task struct to keep track of sleeping processes, limits the number of processes the kernel can handle. If you In a sense since wakeup is O(N) by number of processes processes, you can increase functionality. If the number of sleeping processes is more then

Re: A question

2000-06-20 Thread Alan Cox
various extended features (which few use) can then be easily added on a personal basis. I doubt that ELKS has ever run more than 15 processes, for instance. For reference the standard V7 builds were for about 30-60 processes (60 being a big box).

Re: A question

2000-06-20 Thread Greg Haerr
: For ELKS it isnt worth it. For real Linux it would be (and in fact it does : it all with lists) Although these suggestions about making extendable sleep structs are laudable, I, for one, agree with Alan. I think ELKS is a great learning tool, and should function simply. I've found that in

Re: A question

2000-06-20 Thread Blaz Antonic
cases even ELKS code is too complicated. Alan has pointed this out with the #ifdef madness and other very little used options. Most of IFDEFs were there due to bugs in the source .. old code was just #if 0ed out and replaced with new one. At least that's what i did in parts of kernel i