ramdisk/shell problem?
I'm using 0.0.81 elks and I'm trying to make a ramdisk with the ramdisk utils. When I enter ramdisk, it says something like usage blablabla, but when I give options such as suggested by that, it says ramdisk:no such file or directory. Now I thought this might be a shell problem, so let me add that I use sash, but ash also gives the problem. What to do? Groeten, Dries p.s. Apart from trying to read the source codes, what can one do to understand ELKS. I would like to play around with it, since it is less complicated then the full linux kernel. My background is in mild linux kernel module programming.
Re: Common letters in the Alphabet.
Simon Wood wrote: > > For ELKSibo I have had to include a font bit map (as I have to draw each > character to the LCD), this only has a few of the 255 ASCII codes and is the > form: > ASCII Value, data, data, data, etc, > > The renderer compares the first byte with it's desired character and moves > to the next character should they not match. > > I would like to sequence the data so that the most common characters are > near the start of the list and therefore speed up the display driver > (believe me every little bit helps). > > Does anyone have letter probability table I could use??? (or any idea how to > generate one) Letter probability is closely related to the letter typed earlier. Maybe it's an idea to enlarge the size of you fint bit map struct and store after each character a pointer to the character most likely to follow it. The probability table could be easily found by simply downloading a few books in the language of your choice and have a script count letters and correlations between letters. Furthermore I don't quite understand why you choose to step through the font bit map structure. If you have stored it as an array, isn't it simpler to simply use the ascii code as a memory index. This would only require you to place the array at a smart location (for instance at the beginning of some segment or an integer number of pages from it) so that you can avoid having to do multiplications when calculating the memory adress. If you fix it in such a way that each entry in the array is some power of 2 bytes long, you can calcuted the memory adress from the index by doing a shift and an add. Correct me if this is a stupid idea, I'm ne wat this. > > Simon Wood Dries
Re: A question
On Tue, 20 Jun 2000, Alan Cox wrote: > > Could anyone explain me what is a V7 like wakeup mechanism? > > Old old unix systems took the address of the thing they wanted to wait on > and placed it in the task structure. Since the number of processes is pretty > low its easy for the CPU to walk the process table on a wakeup checking > if the 'wakeup' for this process matches the value it is given to wake. Since a realloc is a pretty expensive call, this pretty much means that you have to allocate enough memory for the task struct to fit every process you will be running. This would mean that you have to allocate too much memory to be on the safe side. Isn't it possible to make a kind of 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 machines ELKS runs on, I can imagine that you could choose the memory in such a way that a all kernel processes, with a few users processes (say 2 or 3) fit in on struct and that if the user is stupid enough to try to do serious multitasking on his 8086 or palm pilot, the kernel allocates another struct, the pointer to which is stored in the original struct. This way you have the best of both worlds it would seem. Is this stupid? Has it been tried? Groeten, Dries
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
On Tue, 20 Jun 2000, Larry Howard Mittman wrote: > 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. This is exactly what I mean. This would make ELKS scalable enough for the people stupid enough to try *grin*. > > -- > == > Never cross a Dragon, for you are crunchy and taste delicious! > My Interests are: > Ham Radio (N8MGU) | Opera | Theater | Sailing | Judaica > > > Groeten, Dries
Re: A question
On Tue, 20 Jun 2000, Alan Cox wrote: > > 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). Oh, ok, I had no idea of the scale. Forget what I wrote *grin*. > > > Groeten, Dries