Re: A question
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 dont follow you 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 allow a situation where the list of sleeping processes is stored in the task struct, but can also contain a pointer to another list of sleeping processes, you can increase functionality. If the number of sleeping processes is more then a certain number, you can activate the pointer and the kernel can follow the pointer like in a linked list. So you don't really use a linked list like linux does, but you use an array and when it's full, you can point to another array. I usually only do a bit of kernel module programming and I'm following the ELKS mailing in hope of learning a bit more about things like scheduling, so forgive me if what I say sound a bit stupid *grin*. Groeten, Dries
Re: A question
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 understand him correctly, the idea is to make the struct one node of a Btree -like construct. IE: (struct-of 2-or3-processes)(link to next struct) That way, with a minimal amount of processes (2,3,4, or 5) you would have one struct, just as you described. But, if you try to have more, the struct chain grows by another struct (2,3,4,or 5), etc... If you are crazy enough to have MANY processes, the chain would grow accordingly and so would the time necessary to traverse it. But with a small amount, (small being relative to personal taste), the response would be acceptable. -- == Never cross a Dragon, for you are crunchy and taste delicious! My Interests are: Ham Radio (N8MGU) | Opera | Theater | Sailing | Judaica
Re: A question
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 a certain number, you can activate the pointer and the kernel can follow the pointer like in a linked list. So you don't really use a linked list like linux does, but you use an array and when it's full, you can point to another array. For ELKS it isnt worth it. For real Linux it would be (and in fact it does it all with lists)
Re: A question
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
: 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 many cases even ELKS code is too complicated. Alan has pointed this out with the #ifdef madness and other very little used options. The ELKS project should function as simple as possible, IMHO; 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. Regards, Greg
Re: A question
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 touched; Al then included whole patch (or file), without removing old code. Anyway, it was harmless. on a personal basis. I doubt that ELKS has ever run more than 15 processes, for instance. No, it probably hasn't. I had some 10 running but then again i was only testing it. If there was _any_ daemon present it would occupy another process slot, ... bye, Ab
